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In this Issue 

I Optical data storage technology offers several advantages over magnetic 
storage. Optical disks are more durable and reliable, have greater storage 
capacity, and cost far less per megabyte than magnetic disks. On the other 
I hand, optical access time is currently much longer than magnetic, so don't 
look for optical disks to replace magnetic disks completely any time soon. 
There are three optical storage technologies: compact disk read-only mem- 
ory (CD-ROM), write-once-read-many (WORM), and rewritable optical. CD- 
ROM is basically the technology that is used for compact disk audio recording. 
The data is represented by pits on the disk surface, which are read by a 
laser system, WORM technology also stores the data as pits, but the pits are created by a 
high-power laser instead of by duplicating a master disk. Rewritable optical technology also comes 
in three types, but only one — magnetooptical— is currently practical. Data is stored magnetically 
on the disk. It is written and read optically using a laser system and can be erased and rewritten 
repeatedly without wear or degradation. 

HP offers both CD-ROM drives and rewritable optical disk drives and autochangers. The article 
on page 6 describes the autochanger concept and architecture. Officially called the HP Series 
6300 Model 20GB. A rewritable optical disk library system, the autochanger is the key element in 
a concept called direct access secondary storage, or DASS. The idea is that if you could have 
all of your data on-line, even archival data, you'd prefer that to off-line archival storage on reels 
of magnetic tape. The Model 20GBA stores 20.8 gigabytes of data on 32 magnetooptical disks. 
Access time ranges from a fraction of a second if the required disk is in one of the two built-in 
magnetooptical drives to 15 seconds or less if a disk needs to be exchanged. Besides archival 
storage, the autochanger is designed for backing up large systems without operator Intervention 
and for data-intensive applications such as electronic image management. The major autochanger 
design issues were the mechanical design (page 14), the servomechanism design (page 24), 
qualifying the vendor-supplied drives (page 35) r and integrating the autochanger with the HP-UX 
operating system (page 11). Reliability was the overriding concern, since the autochanger is 
intended to serve as a vital link in a company's computer operations. It's designed for a lifetime 
of a million exchanges. 

The HP Series 6100 Model 600 A CD-ROM drive (page 38) is designed for providing such 
things as software manuals for computer systems, large reference documents, training packages, 
and large-scale software distribution. Each disk can store over 500 megabytes of data Design 
issues included the implementation of error correction (page 42) and software protection (page 
49), integration of the drive with the HP-UX operating system (page 54), and the design of the 
controller board for the vendor-supplied drive mechanism (page 38). The ISO 9660. High Sierra 
Group standard format is used for recording data, so the Model 600 A can read non-HP CD-ROM 
disks and audio CDs recorded using that format. 
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Jn HP s PA-RISC architecture, pnnters, terminals, and personal computers connect with HP 
3000 PA-RISC computers through remote multiplexers called data communications and terminal 
controllers, or DTCs. The host computer and the DTCs are connected by a local area network. 
For wide area communications, packet switched networks, both public and private, are now 
common, and the DTCs can connect directly to these networks, which are defined by an inter- 
national standard. CC3TT recommendation X.25. Asynchronous devices such as terminals and 
printers can connect to X.25 networks through hardware or software elements called packet 
assembler disassemblers, or PADs. PAD support software allows the DTCs to communicate with 
PADs o^er the network. In the HP architecture, the PAD support software is assigned to the DTC 
rather than to the host HP 3000 system. This is done to maximize performance. The article on 
page 63 describes the design, development methodology, and testing of the PAD support software 
for the HP 2345 A DTC. One of the test tools was a message machine that simulates the environ- 
ment of the software under test. Designed using object-oriented concepts, the message machine 
is described in the article on page 74. 

Copper beryllium (CuBe) alloy is widely used for spring contacts in the electronic industry. On 
page 88, Nguyen Hung of HP Singapore reports on an investigation of the dimensional changes 
of cold-drawn CuBe during aging at elevated temperatures. The results show that the changes 
are anisotropic and agree well with theoretical predictions. 

December is our annual index issue. The 1990 index begins on page 81. 



R.P, Dolan 



Cover 

Magnetooptical disk cartridges are shown with various mechanical parts designed for the HP 
Series 6300 Model 20GB/ A 20-gigabyte rewritable optical disk library system. 



What's Ahead 

Lightwave component analysis with modulation rates to 20 GHz is the major topic in the February 
issue. The design of the HP 8703 A lightwave component analyzer, the HP 83420A lightwave test 
set, and related products will be presented. Also featured will be the design of the HP 81 53 A 
lightwave multimeter, a modular instrument for optical power measurements and other basic fiber 
optic mesurements, HP VUE, a visual user interface for the Domain and HP-UX operating systems, 
will be the topic of the lone software article. 
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A Rewritable Optical Disk Library System 
for Direct Access Secondary Storage 

This autochanger system can store up to 20,8 G bytes of 
data on-line . Applications include archival storage, 
automated backup and recovery, and document storage 
and retrieval. 

by Donald J. Stavely, Mark E. Wanger, and Kraig A. Proehl 



HEWLETT-PACKARD MANUFACTURES a wide range 
of computer peripherals. Customers for these 
peripherals include not only users of HP systems, but 
also OEM customers and others who use HP peripherals 
with non-HP host systems. 

Supplying peripherals lo OEM customers has been a 
major initiative for Hewlett-Packard and has had a large 
unpad on how we plan and evolve our business strategies. 
To be successful in the OEM business has required that 
we develop a broader and more timely understanding of 
the market than we had in the past. We feel that our experi- 
ence as a system company gives us valuable insights into 
how our peripherals work in systems and applications to 
solve real customer needs. 

HP's Greeley Storage Division is responsible for high- 
end secondary storage devices that are used for backup and 
archival storage on computers, mainframes, and n el works 
of workstations. Our current product offering is a family 
of low-cost, autoloading, streaming, 1' 2-inch CCR tape 
drives, 1 

As we looked to the future, we naturally focused our 
attention on advances hi tape technology. Emerging prod- 
ucts were usingair bearings formedia reliability, athin-iilm 
18- track head for very high transfer rate, and a compact 
tape cartridge for ease of handling. Initially* this technology 
seemed a good match to what our current HP and OEM 
cuslomers needed, Customers were asking for faster backup 
to reduce planned system downtime — or more accurately, 
to keep from increasing their downtime as their disk storage 
requirements grew. They also need ever higher levels of 
reliability to minimize unplanned system downtime. 

Unfortunately, simplistic market research — asking cus- 
tomers what they want — oflen yields only predictable and 
simplistic answ T ers, They want what they have now, only 
faster, cheaper, more reliable, and so on. In other words, 
customers may be too close to their problems to see thern 
from a new perspective, 

We evolved a much more powerful market research p ro- 
th at consists of three steps. The first step is to gain a 
thorough knowledge of how customers do business. What 
applications do they run? How r much disk space do they 
have? How do they do backup today? What else do they 
use tape drives for? 

The second step of the process is to try to solve customers' 
problems in the abstract — matching available technologies 



to a high-level model of each customer's business, The last 
step is to present a coherent vision of the future back to 
our customers, In essence, we are trying to help thern look 
past the limitations of today's solutions and help them 
architect the solutions of tomorrow. We call this developing 
an "imaginative understanding of user needs," 




Fig. 1 . The HP Series 6300 Model 20GBtA rewritable optical 
disk library system stores up to 20.8 Gbytes of data on 32 
optical disks An autochanger automatically selects the cor- 
rect disk and inserts it info one of two internal drives* 
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Ill probing more deeply with both HP system customers 
and OEM customers, we found that their responses to our 
simplistic market research were indeed conditioned by tin- 
properties and limitations of tape technology. The truth is 
that customers don't like tapes. Tapes are inherently off- 
line devices requiring sequential access to data and 
t\cir intervention to handle the media. What customers 
really want is direct access to all of their archival data, 
without special utilities and without operator intervention. 
We call this concept direct access secondary storage, or 
DASS. When we clearly articulated this concept and fed 
it back to customers, we received consistently positive re- 
sponses. 

Rewritable optica] disk technology, configured in an au- 
tomated library, has exactly the right properties to meet 
this customer need for direct access to archival data. Opti- 
cal disks are removable, rugged, reliable, and fairly inex- 
pensive on a eost-per-megabyte basis. Transfer rates are 
competitive with many current tape products. And because 
it is a disk drive, an optical disk drive attaches to the host 
system using standard disk drivers and file systems. This 
can give direct, transparent access from current applica- 
tions without modification. The connection between opti- 
cal disks and secondary storage makes perfect sense, but 
it was not obvious to either customers or the optical drive 
vendors themselves. 

The optical disk autochangcr plays the other key role in 
the DASS concept. With many gigabytes of on-line Win- 
chester-disk storage, a typical host system requires ten 
even hundreds of gigabytes of secondary storage for backup 
and archival information. In the DASS concept, this sec- 
ondary storage must be on-line — accessible without operator 
intervention or special recovery utilities. Rewritable opti- 
cal drives in an aulochanger configuration provide a cost- 
effective answer In the customer need for direct access to 
huge amounts of historical Safe. 

Reliability is the single most important attribute of an 
autoenanger. The customer perception is that autocbangers 
are "mechanical nightmares" that are fascinating to watch 



at trade shows but frightening to consider as a vital link 
in a company's computer operations, It was for this reason 
that Hewlett-Packard chose to design and build its own 
autochanger mechanism. 

The philosophy used to guide the development was that 
reliability should not be tested into a product, nor even 
designed in — it must be architected in. An architecture (hat 
minimizes complexity, followed I .1 design and 

rigorous testing. Is the only way to achieve a quantum leap 
in reliability 

Optical Disc Library System 

The result of these considerations is the HP Series 6300 
Model 2 0GB /A rewritable optical disk library system, Fig. 
1. The Model 20GB/ A combines the convenience and low 
storage cost of optica I- disk technology with the massive 
capacity of a library system to provide on-line access to 
vast amounts of infrequently accessed information. The 
Model 2 0GB/ A is a direct access secondary storage [DASS] 
device that fills the price/performance gap between high- 
performance hard disks and low-cost tape storage (Fig. 2). 
Because of its huge, 20.8-Gbyte storage capacity and low 
( 03I per megabyte (Fig. 3) r the product makes it feasible to 
store information on-line that has traditionally been stored 
off-line, and to automate labor-intensive backup and recov- 
ers processes. It also greatly reduces Ehe floor space re- 
quired lor archiving [Fig. 4). 

The Model 20GB/A uses niagnetooptical technology (see 
box. page tf). Data is stored on removable 5 Winch disks. 
Optical disks are not susceptible to head crashes and are 
much more tolerant of magnetic interference than magnetic 
media. Fingerprints and small scratches have no effect on 
the dala. Data can last over ten years without the ^tension- 
ing or reconditioning thai tapes require. 

The Model 20GB A consists of an autochaoger, I wo mag- 
netooptical riisk drives, and 32 5 1 Vinoh , fi5u-Mbyte optical 
disk cartridges in a deskside cabinet. A mailslol is provided 
for loading or removing disks. The autochanger automati- 
cally selects the appropriate cartridge and inserts it into 

(continued on page 1 0) 



Primary Storage 

*High- Performance 
Hard Disks 

-Performance; Access in ms 
-Costs; S15-S20 Mbyte 




Secondary Storage 

'Sequential Tape Drives 

-Performance: Access in min 
Cost: SO. 1 5-0.20 Mbyte 



DASS 

'Rewritable Optical 
Disk Drives 
and A utoch angers 

-Performance: Access in 0.1-15 b 
-Cost: SO. 38 Mbyte (Media Only) 



Applications 

* H i sto ri c a f . A re h i va I St o rag e 
{InfrequenUy Accessed Data) 

'Unattended Backup Restore 
(Automated Operations) 

"Document Storage and Hetrieva! 
(Electronic Image Management) 



Fig, 2. The optical dtsk library 
system is a direct access second- 
ary storage (DASS) device, tower 
tn cost than high-performance 

dtsk dnves. but higher tn perfor- 
mance than iow-cost tape. 
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Magnetooptical Recording Technology 



Rewritable optical technology today encompasses three differ- 
ent methods: 
■ Magnetooptical 
B Dye- Polymer 
a Phase^Change 

The most durable and predominant technique in the market 
today fs magnetooptical. This discussion will be limited to this 
technique, which is the method that Hewlett-Packard has chosen 
for introducing rewritable optical technology for direct access 
secondary storage. 

Magnetooptical technology relies on the storage of information 
on a thin film of magnetic material. Like conventional magnetic 
recording, the information is stored on the media in the form of 
magnetic domains. The domains are aligned vertically, in contrast 
to most magnetic recordings today, which are based upon lon- 
gitudinal magnetization, The important and significant difference 
comes from the fact that the processes of writing, erasing, and 
reading are performed with a light beam derived from a solid- 
state laser and associated optics, not by mechanical heads (hat 
come into contact or near contact with the recording surface. 
This attribute allows optical recording to have longer life and 
higher reliability than tapes and flexible disKs. Optical disks are 
immune to the typical wearout modes that occur with contact or 
close proximity recording. 

Recording 

Therm cm ag net ic writing is the term used to describe the pro- 
cess of writing information on a thin magnetooptical film. The 
laser beam heat -modulates the magnetic film about its Curie 
temperature. The Curie temperature of a magnetic material is 
the temperature at which the material loses its coercive magnetic 
field. Thss occurs between 150 Q C and 200 S C for typical mag- 
netooptical thin fiims. When this occurs, the material loses all 
memory of its prior magnetization and can acquire a new mag- 
netization as it cools in the presence of an external magnetic field. 

The writing process is shown schematically in Fig 1. The re- 
corded information is stored on the magnetic medium by revers- 
ing a magnetic domain to store a one and by not reversing a 
domain to store a zero. Thus the precondition for writing informa- 
tion is for all domains to be initialized to the zero state. This 
means that, to overwrite data, an erase pass must be performed 
before the write pass to set up this initial condition of all-zero 
domain alignment During the erase pass, the laser is turned on 
to heat the magnetic domains and an external magnetic field is 
applied in the proper orientation to change all of the domains to 
the zero state. 

Data can be written on the erased track during a subsequent 
disk rotation. With the polarity of the external magnetic field re- 
versed, the laser *s turneo on and off to heat only those domains 
that are to be changed to the one state. The external magnetic 
field required to erase or write data is supplied by a bias magnet 
which is typically positioned on the opposite side of the him 
surface from the optical head. This external bias magnet must 
have the ability to change magnetic polarity; therefore, it is typ- 
ically an electromagnet or a permanent magnet that can be 
mechanically rotated to accomplish polanty changes 

When magnetooptical films are at room temperature, they typ- 
ically exhibit coercivities of several thousands of Oersteds. This 
means that in the absence of laser heating, the magnetic field 
required to affect their state of magnetization is extremely large. 
Because of these high coercivities at operating and storage tem- 



peratures, magnetooptical records are less susceptible to darrv 
age from external fields than records on conventional magnetic 
storage materials such as those on flexible and rigid magnetic 
disks. 




Coil with 
Polarity Reversed 



Fig. 1 . The magnetooptical write process, (a) AH of the mag- 
netic domains are magnetized north-pole -down. This ail-zeros 
state is the precondition for writing, (b) The iaser beam turns 
on for each domain that is to store a one Heating the domain 
above the Curie temperature causes tt to lose its previous 
magnetization and orient itself with the external magnetic field 
of the bias coif (cj To erase the data r the polarity of the 
external field is reversed and the laser is turned on, returning 
all of the magnetic domains to the condition shown in (a). 
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Readback 

For data readout .information <s extracted ?oop- 

Tt by reflecting a polarized light beam off the m= 
film surface and defecting a change In the angle of polar , 
of Ihe reflected Dear omenon. upon which 

She magnetooptical rewntable technology is oased is known as 
the Kerr ef - ^Tested as a change in the state of polari- 

zation of light upon interac I 3 magnetized medium The 

amount of polarization rotation is small (Jess than one degree) 
Out techniques used in film manufacturing can enhance the ef- 
fect In aadiTiar; a variety of detection and readout techniques 
have been developed to enhance the magnetooptical signal, As 
a result, good signal-to-noise ratios of 60 d8 or more can be 
achieved. 

Another magnetooptical readout alternative is based upon the 
Faraday effect This effect is similar to the Kerr effect but relies 
on light transmitted through magnetic films. The interaction of 
the light with the film causes polarization state changes This 
technique is not employed m the magnetooptical rewritable pro- 
cess primarily because of the low transmission^ of magnetoop- 
tical films and the difficulty of placing interactive optics on both 
sides of the media, 

Magnetooptical Materials 

MagnetoopncaJ materials are composed of a rare earth ele- 
menl and a transition metal. Typical rare earth elements used in 
magnetooptical recording include gadolinium (Gd, z = €4} and 
terbium (Tb, z = 65). These rare earth elements are also called 
lanthanides. These elements are soft, gray metals that have good 
conductivity As a group, the lanthanides are not very abundant. 
The most common lanthanide is cerium, which makes up only 
3x 10~ 4 percent of the mass ol the earth's crust. The transition 
metals commonly used in magnetooptical recording include iron 
(Fe, z = 26) and cobali (Co, z = 27). These elements contribute 
characteristics such as high melting temperature, good conduc- 
tivity, and fairly high hardness Alloys of rare earths and transition 
metals sre amorphous and have been processed to achieve a 
high level of chemical stability. The transition metal provides ihe 
dominant magnetooptical interaction (Kerr effect) while the rare 
earth element helps to provide high vertical magnetic anisotropy. 

Curie and Compensation Temperatures 

The important parameters in processing magnetooptical films 
are the Curre temperature of the alloy (mentioned earlier} and 
the compensation temperature. The compensation temperature 
is the temperature at which the magnetization component of the 
transition element is equal and opposite to that of the rare earth 
element, so that the net magnetization is zero The compensation 
point can be either above or below the ambient temperature At 
the compensation temperature, since there is no net magnetiza- 
tion, the material cannot interact with external fields. Therefore. 
the coercivity is extremely high and the magnetic domains are 
very stable For practical magnetooptical recording hlms in use 
today, the compensation temperature is kept well below the Curie 
temperature and the lowest operating temperature the film will 
see. The reason is that the interaction of the compensation point 
magnetic behavior can affect the requirements for Curie temper- 
ature recording. If the compensation temperature is in the region 
of operation, the magnetic properties change dramatically and 
can interfere with the designed magnetooptical recording pro- 
cess 

The compensation point lor magnetooptical films is determined 
by the percentage of the rare earth element in the film Typical 
percentages, for example, are for terbium to be below 19 to 20 
atomic percent lo keep the compensation temperature below 




Adhesion Layer 
Magnetoophc Layer 
Reflective Layer 
Protective Layer 

Adhesive Layer 

Polycarbonate Layer 

Fig. 2. Magnetooptical disk construction 

ambieni It the percentage of terbium is higher, say above 22 so 
23 atomc percent, then the compensation temperature can ex- 
ceed ambient At percentages greater than 27 or 2B atomic 
percent there is no compensation temperature because the com- 
pensation temperature exceeds the Cune temperature, and mag- 
net c properties above the Cune temperature dominate the film 
behavior 

The Cune temperature *s selected so that the laser light source 
can easily raise the magnetooptical film material lo this temper- 
ature without exceeding lUe design limits on the laser power A 
film with a lower Curie temperature requires less heal and there- 
fore fs more sensitive Hence the Cur ?e temperature controls the 
media sensitivity 

The Cuhe temperature for magnetooptical films is determined 
by the selection of the transition metal component One way to 
control the Curie temperature is to adjust the ratio of cobalt to 
iron in the trans. [ion metal As the ratio of cobalt to iron ss in- 
creased, the Cune temperature is increased and the film sensitiv- 
decreased — more power :s required to reach the Cuhe 
temperature 

Manufacturing 

The manufacturing processes for magnetooptical disks have 
to take into account a wide variety of parameters. Important 
considerations include the following 

■ Mechanical stability of the substrate, which is typically plastic 
(polycarbonate). Glass and aluminum have also been used 
Some of the parameters of concern are warp, tilt, ax<a! and 
radial runouts, and accelerations, 

■ Birefringence of the substrate, a condition in which the index 
of refraction is dependent on the polarization of the light. 

■ Dust protection This is provided by a transparent layer that 
keeps dust scratches, or other optical disturbances away 
from the focal plane of the recording surface 

■ Surface reflectance control This requires control of layer 
th ckn esses and refractive indexes. 

■ Thermal characteristics, including thermal properties of films 
and surrounding structures and materials 

■ Magnetic properties, which are determined by film composi- 
tion and thicknesses 

■ Protective coatings, such as dielectric barrier films for corro- 
sion protection, 

A typical cross section of a magnetooptical disk is shown in 
Fig 2 The disk consists of two ten-nanometer-thick layers of 
magnetooptical film — one for each side of the disk — >sandwrched 
between two polycarbonate disks. Dielectric material and ad he- 
si ves separate and bond the layers 



Ed Sponheimer 

Project Manager 

Greeley Storage Division 
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oil© n( \Ur \\w, Internal drives, Operaiinn i$ inmspan-ni to 
users, who see only a slightly slower response timH when 
accessing Optically slurtsd data — apprnximalely 1(K) mil- 
li seconds if the disk is id ready in a drive, or about 10 to 
15 seconds if disks need to be exchanged. The HP-UX 
operating system recognizes each disk side as a 3 25- Mbyte 
mountabie file system, so data access and software compati- 
bility are the same as if the library system were a (slower) 
hard disk- 

The Model 20GB/A conforms to ANSI and ISO specifica- 
tions for continuous composite formal 5V*-inch rewritable 
optical disks. This ensures compatibility with the HP Series 
6300 Model 6 50/ A stand-alone rewritable optical disk drive 
and the drives and media of other manufacturers. The sys- 
tem implements the Small Computer System Interface 
(SCSI) in asynchronous mode with separate IDs for both 
drives and the autuchan^er. The product Is supported on 
HP 9000 Series MEM) and BOO computer systems running the 
HP-UX 8,0 operaling system, 

Design Philosophy 

The design criteria lor the HP Series 0300 Model 2UGB/A 
revvrilable opl it a I disk library system were focused on three 
points that we felt were essential to the successful launch 
of a peripheral with ueu functionality: minimizing time 
to market, making the product very reliable- and complet- 
ing full system integration. The major design and architec- 
ture philosophies we used were high leverage of existing 
successful designs, design simplicity, and modular design 
with Limited coupling between modules. 



I i ' up d designs allowed us to produce early bread- 
boards rapidly with a high level of sophistication. In using 
leveraged designs, we tdso gained all the benefits of liir 
engineer-years of effort that went into reliability engineer- 
ing. We leveraged coupled servo architecture, motor/en- 
coder design, a proprietary IIP motor control IC pulley 
and lie] I design practices and capabilities, and carriage and 
way design We limited ourselves to off-the-shelf power 
supplies to decrease risk and tooling expense. 

The design lor reliability began with a studv of failure 
rates on HP plotter producls dud the HP quarter-inch 1 ri [ n * 
< arfridge autochanger. We found lhat the predominant fail- 
ures were associated with sensors, swatches, motors, and 
solenoids, We next generated graphs of annual failure rale 
as a function of the number of sensors and as a function 
of the number of actualors. The architecture dial followed 
from this analysis called for a minimum number ol sensors 
and motors, and for a " passive pailn.id" dr.-,i^n, which 
means that no sensors or actuators were allowed on any 
moving parts. This strategy decreased the number oi liigh- 
failure-rate parts and supporting parts as well, such as 
cables, connectors, and flexible circuits- It also eliminated 
flexing wires, which have fatigue problems. We were well 
aware that as printers have evolved in reliability, the hard- 
esl remaining reliability problem is the flexible cable going 

10 ihe printhead. 

The mechanical design of I lie au I oc hanger is described 
in the article on page 14. 

Another feature of the design is the servomechanisiu 

11 sense of touch," which is tied directly to the passive 

(continued on page Jj£) 



Drive(s) Plus 
Media Only Media for 20 Gbytes 



46.5 






«- 4.0 



o 
O 



20.00 20.00 




20GB A High-Capacity High-Capacity Paper 
Optical (6250 bpi) Fixed Disk Archive' 

Library Tape 

'Varies with application. Conservative estimates are 0.01 per page and 
0,02 per page with storage and retrieval 

Fig. 3. Storage cost per megabyte for various alternates. 



8 4 — 



o 
o 

u 



£? 

CO 
S 

S 




20GB A High-Capacity 
Rewritable VHnch Tape 
Optical Library Library 
System (Two Drives) 



Fixed 
Disks 



Paper 
Archfve 



Fig* 4. Storage space comparison for 20.8 gigabytes. 



10 HEWLETT-PACKARD JOURNAL DECEMBER 1990 



)Copr. 1949-1998 Hewlett-Packard Co. 



Integrating the Optical Library Unit into the HP-UX Operating System 



The HP Series 6300 Model 206B,'A rev, 
brary autochanger ts unlike any 01 her peripheral supported on 
the HP-UX operating system and therefore required a new ap- 
proach to rntegraiton into the operating system On one hand, 
its random-access attributes suggest a connection with the 
operating system that is disk-like. On the other hand, its need 
to share multiple disks with one or two drives hints at something 
ay need specif j c user or application support 

Although the design options were unrestricted we wanted an 
integration method that would satisfy two overriding goals Rist 
the integration method should hide as much as possible the 
requirement to swap disks -nto and out of the drives This trans- 
parency goal means that no special programs or utilities are 
required to access information on the autochanger This holds 
lor commands that rely on network services as well as commands 
that treat mass storage peripherals as raw devices. The second 
goal was that the integration method should have minimum im- 
pact (complexity, coupling , etc ) on the HP-UX operating system 

Design Choices 

The accepted way of integrating WORM (write once, read 
many) autocfiangers relies heavily on the application. An appli- 
cation is provided with low-level control of the changer mecha- 
nism ano low-level control of the drives The application :s respon- 
sible for swapping disks in and out of drives and tracking the 
location ot disks. This method clearly does not allow transpa- 
rency, but our solution needed to support this low-level control 
so that existing applications that already rely on it could be ported 
to HP-UX and so that other autochanger- specific utilities could 
be developed The HP-UX ioctl system call is used to support 
these low- 1 eve I commands 

A tempting way lo model the integration is to view the entire 
autochanger as one large disk This solution implies that the disk 
cartridges that make up this large disk travel as a group and 
remain in some logical order Since disks in the autochanger are 
inherently removable, the admrnislralive problems of keeping 
sets of disks together led us away from this solution 

The solution we settled on treats each side of a disk as an 
individual disk. 1 The system administrator is free to create tile 
systems on these disks and mourn ihem or access them in the 
raw mode using existing system calls such as readO. wriieo, and 
other utilities that use raw devices. A file system residing on an 
ir idividual disk surface can be mounted anywhere in the directory 
structure of the HP-UX tile system. 

Neither existing commands nor application programs require 
modification to mainiarn their functionality. The file systems resid- 
ing on cartridges maintain therr NFS (Sun Microsystems" Network 
File System) functionality with other machines on I he network 
The file systems are also protected from power failure to avoid 
lengthy file system recovery processes. 

By confining most of the changes to a driver, the goal of 
minimising HP-UX changes was met Fig t illustrates the struc- 
ture of the autochanger driver The aulochanger driver consists 
of two main parts: the surface driver and the changer driver. The 
existing disk driver is used to control the drives This is the same 
driver that controls the stand-alone rewritable optical drive, the 
HP Series 6300 Model 650/A 

The changer driver provides low-level control of the au- 
tochanger mechanism It accepts commands to move the disk 
in slot x to drive 2, to report whether there is a disk in slot 2, and 
similar tasks, The surface driver controls the swapping of disks 



and routes disk requests to the disk driver when the requested 
3 rive 

The Swapping Algorithm 
When requests for different surfaces occur, only one of those 

surfaces can be inserted into each dnve The other requests 
must be suspended To avoid having these requests wait forever, 
we set a limit, called the hog time, on the time that a cartridge 
can be in a drive processing requests while other requests are 
waiting Once this time expires, that cartridge is removed and 
the request waiting the longest is inserted We have found that 
the hog time should be somewhat larger than the time required 
10 exchange a cartridge. Twenty seconds has proved sufficient. 

If a cartridge in a drive were to be replaced immediately when 
there are no additional requests tor lhal surface, it is possible 
that shortly after the cartridge exchange is started, a request for 
the original surface could arrive. This could result in a cartridge 
swap for every request To avoid this problem an additional limit 
called the wait lime was added This is the maximum time that 
a cartridge can reside m a drive without processing any requests 
while other requests are waiting to use the drive. Choosing the 
wait time too large increases the effective swap time of the au- 
tochanger. Making the wail time too small increases the chances 
of thrashing as a result of consecutive requests for the same 
surface. We found a wait time of one second to be suffir 
avoid the extra swapping in most instances. 

Because we realize that certain configurations will require dif- 
ferent hog and wait times, these values are configurable (via 
drive ioctl calls) while the system ks running For example, in a 
backup application, the hog time should probably be high, so 
that other processes won't seriously degrade the throughput. II 
an application program reads blocks of data and then processes 
that data tor more than a second before it reads more data, the 
wait time should be increased to avoid swapping between reads 

Autochanger Driver Design 

The design of the autochanger driver overcomes three prob- 
lems 

■ It avoids a file system check (the Etefe command) of ail the 
cartridges after a power loss 

■ It avoids excessive swapping caused by the syncer. 

■ It supports ihe concept of asynchronous read and write operations. 



File System 




Fig. 1, The autochanger driver consists of a surface driver 

and a changer driver. The existing disk drtver Is used to 
control the optical drives 
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Avoiding a Lengthy fsck The superuser must execute the mounl 
command for each surface to be accessed before users can 

perform file system operations lo the autochanger Normal Win 
Chester disks require a file system check H the power cycles 
while the disk is mounted. Since we do not want to require trie 
user to check every surface, which could lake several hours, we 
make sure the tile system on every disk is m a known, valid stale 
before the disk is removed from a drive. 

To do this, the autochanger driver uses the concept of virtually 
mounted devices A virtually mounted device is not vulnerable 
to power faslure corrupiion of its file system When a device is 
virtually mounted, it is noi directly connected to Ihe rest of Ihe 
file system Only basic information aboul the file system and 
device is stored The file system is available for use, bui fries 
cannot be accessed until the device has been physically 
mounted. 

Cartridges in the autochanger that are waiting in their slots are 
only tfirty&lly mounted When a file on a virtually mounted device 
is referenced by a user. The file system code uses the stored 
information to mount the device physically before the ftle is ac- 
cessed. When the operations on that device are finished, the file 
system physically unmounts the device This causes any buffers 
ir\ the host that were not written to the device to be flushed The 
file system is now in a state that would not require file system 
repair on a power failure. Cartridges only need to be virtually 
mounted when the system is first booted 

Avoiding Extra Syncer Swaps, To limit the number of modified 
buffers that haven't been written to the disk at the time a power 
farlure occurs, there is a process that executes periodically that 
flushes these buffers. This process, called the syncer. schedules 
all The modified butlers io the drivers so they will be written to 
Ihe disk. If a surface is removed from the drive without flushing 
all the modilied buffers, the syncer will execute and require the 
cartridge to be reinserted Having several cartridges mounted 
can cause excessive thrashing 

The solution is to write all Ihe modified buffers tor a surface 
before The cartridge is removed. This is done as part of the 
physical unmounting process 

Supporting Asynchronous QppnitUins. bvery block device 
driver in the HP UX kernel must be able !o support the concept 
of asynchronous requests. An asynchronous request essentially 
means that when the file system makes a rcquesi to tne drive to 
perform say. a write to disk, the driver should queue the request 
and immediately return without actually doing the I'D Thus tends 
to pose a problem in that, once the request is queued, some 
thread of execution must eventually complete the request The 
normal method of doing thrs is through hardware-generated inter- 
to" the driver. However, this interrupt structure is absent in 
the autochanger driver 

There are two basic ways to solve thrs problem One is to 
provide the extra thread of execution through the disk driver's 
tnterrupt calls This adds extra complexity and coupling to both 
of the drivers. The method we have chosen is to create extra 



kernel daemons to provide the extra threads of execution neces- 
sary Two daemons are used. A transport daemon is responsible 

for moving the cartridges, and a spinup daemon is responsible 
for spinning up the drive The two daemons make it possible to 
overlap moves and spinups For example, after a cartridge has 
been put into a drive and begins to spin up, the picker can be 
used to move another cartridge out of another drive. 

The transport daemon flushes the asynchronous write opera- 
tions to the disk before it removes a cartridge from a drive The 
spinup daemon flushes all the waiting asynchronous requests 
to a new cartridge that has just been put mlo a drive Thus, all 
asynchronous writes are eventually flushed out to a drive If an 
asynchronous request arrives while a cartridge is currently in a 
drive, that request is passed to the disk driver immediately This 
maintains the asynchronous function of the autochanger driver. 
One advantage of this daemon approach is thai n is portable to 
other UNW architectures 

There are four processes in the autochanger driver- Accept 
Requests. Schedule Asyi>c Requests, and the transport and spinup 
daemons Each process represents a separate thread of execu- 
tion Accept Requests executes any requests for surfaces already 
in drives All other requests are queued This process is in charge 
of determining if a swap is to occur as the result of receiving a 
request by checking the hog time and other conditions. The 
transport daemon only runs when Accept Requests determines that 
a swap should occur It atso performs the physical unmounting 
and makes sure the surface in the drive is pul in a consistent 
state before it is removed from the drive. The spinup daemon is 
charge of spinning up the cartridge after it has been inserted It 
also performs the physical mounting and processes any asyn- 
chronous requests waiting to use that drive The Schedule Async 
Request process is executed when no synchronous requests are 
waiting for a surface. Its purpose is to satrsty the requirement 
that asynchronous requests return without waiting for any I/O to 
be performed. This process is not a daemon but is called by an 
interrupt from the wait timer in the spinup daemon, If the wait 
timer times out, Schedule Async Request is started it no synchronous 
requests are waiting to use the drive. 

"UNIX is a 'egiaTdred lrademark ot At&T in [tie LJ S.A grid Gihet countries 
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(comrtUt&d from page 10} 



payload concept. The ability fur the control J er to sense 
forces and distance allowed us to remove physical sensors 
in the hardware. The architecture called for moving the 
sensors from the robot back into the information processing 
capabilities of the motor controller and encoder. Sense of 
touch algorithms allow the controller to sense whether 
there is a cartridge in a location, verify a move, and so on. 

Another reliability enhancement isoverforce sensing and 
error recovery. Using sense of touch, the robot stops motion 



before anything is broken. An error recovery algorithm is 
then invoked to clear the error condition and complete the 
move sequence. This design provides another chance to 
avoid a service Gall* 

IJetails of the servoinechanism design are in the article 
on page 24, 

The design is highly modular with limited coupling of 
the modules This effort paid off in many ways. The design 
areas could be assigned to engineers in a relatively un- 
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coupled way. as long as the interactions of the design mod- 
ules were relatively well-defined . In these design modules, 
functionality was the key. Designers had the ability to 
simplify or redesign with measured effect on the rest of 
the project. This has been very fmilful as the project has 
continued in its life. As reliability concerns are raised, they 
can be addressed with minimum impact on other aspects 
of the design. This allows improvement with limited risk 
of introducing new problems in related designs. 

Trying to achieve minimum system integration time and 
maximum flexibility led to the concept of mounting the 
a ut onhanger in either a stand-alone IIP rack or a standard 
19-inch rack. This would allow the library system to fit 
into many different systems, both HP and non-HP. This 
design was adopted early in the project, and is now being 
born in a follow- on product. 

In selecting a system as an initial host, we chose the 
HP-UX operating system because it provides enough power 
and flexibility to support this peripheral, and is almost an 
open architecture. This provided us with a number of op- 
tions including developing a driver ourselves or developing 
a file level interface. Integration ui the auLochanger with 
the HP-UX operating svsiem is I he subject of the box on 
page il. 

Autoch anger Architecture 

One of the major goals in the design of the autochangcr 
architecture was defining a growth path for future products. 
We did nol want to lock ourselves into an architecture that 
would nol allow us to meet the interface performance de- 
mands of the future, The optical drives that were going to 
be used in the autochanger communicated via the SCSI, and 
since there was a standard emerging tor mi SCSI au- 
tochanger command set, we decided I hat the primary inter- 
face of the autochanger would also be SCSI. 

There are two drives in the standard configuration, and 
this means that the aulochanger needs to use three SCSI 
bus IDs (two for the drives and one for the autochanger 
controller and mechanism). Tins posed the problem that 
il more than two auku. hangers were used by a host on a 
single SCSI bus, the available bus IDs (H) would soon be 
used up. We investigated some other architectures that 
would consume only one SCSI ID, with the autochanger 
and its two drives configured as logical unit numbers 
(LUNs) under that single III However, there were concerns 
about I lie performance degradation of doing the SCSI-to- 
SCS1 command conversion ioi each LUN. 

Even more ambitious than this architecture was the full 
file-level interface concept. This entailed defining an en> 
tirely new interface that interacted on a file level and totally 
hid the SCSI in the drives. With this concept, we felt we 
would have complete freedom to optimize the perfor- 
mance, throughput, and thrashing issues associated with 
an autochanger. On the other hand, this approach would 
also cause us to abandon the SCSI-1! interface standard 
being adopted by most of the industry, and the use of a 
standard interface w r as seen as essential if this product was 
going to have a viable life as an GKM product. 

Although future growth was a major concern, time to 
market was an even greater preoccupation, The auto- 
changer was on an aggressive schedule, so we needed to 



be careful about not taking on too big a task for the lime 
allotted. We were able to satisfy both goals by opting for 
the first architectural option described — the use of three 
SCSI EDs on the bus 

Autochanger Controller 

The autochanger controller board is based on a 68000 
microprocessor. The 68000 controls <dl pro- 

cesses in the autochanger. Because of the architecture cho- 
sen, the (38000 has no direct communication with the mag- 
net ooptical drives over the SCSI bus. The autochanger is 
meant to be an SCSI target device only, and at present does 
not support any initiator Junctions. 

The B&OGG operates with a time-sliced operating system 
whose primary JuiH "ion is to control the two servo loops 
of the V and Z motors. Operation of these two loops can 
unit 1 up to 70% of the processor's 12-MHz bandwidth, 
The remainder ol the processor's time is involved with 
command interpretation and the overseeing of all other 
autochanger functions. 

Commands to the autochanger can come from one of 
three different sources: the SCSI, an RS-232 port, or the 
front panel. The SCSI is the primary means for control ling 
the autochanger. The RS-232 port Is primarily for diagnos- 
tic purposes, although it can also be used as the primary 
interface for the autochanger controller, The front panel is 
the personal, direct user interface Commands can be en- 
tered through each of these interfaces, and although their 
formats differ, they are alt processed through a common 
control flow' in the 68000 firmware. 

The hardware implementation of this architecture is 
highly iulegrated and uses either multifunction or intelli- 
gent nIM he-shell parts. The SCSI is managed by a propri- 
etarv controller IC, which frees the processor from all but 
the most necessary processing tasks of the SCSI bus, The 
RS-232 port is managed by a multifunction peripheral chip, 
which also handles all the interrupt vectoring and generates 
various timers used by the controller. The front panel i:-, 
controlled by an 8051-type microcontroller, winch man- 
ages all the key presses and is responsible for updating the 
vacuum fluorescent display. The low-level servo process- 
ing is serviced by another proprietary IC, which manages 
the duty cycle of each motor and monitors the position 
encoder information, 

The controller board also contains 1BK words of non- 
volatile RAM. This RAVI is used to store critical state infor- 
mation and positional parameters for use in autochanger 
error recovery and powerfail conditions. The nonvolatile 
RAM also i mlii,. i us certain configuration parameters and 
certain logging values that constantly reflect the age and 
health of the machine. 
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Mechanical Design of an Optical Disk 
Autochanger 

The autochanger moves 32 disk cartridges between two 
magnetooptical drives and two stacks of storage positions 
using only two motors and three optical sensors. 

by Daniel R. Dauner, Raymond C. Sherman, Michael L. Christensen, Jennifer L Methlie, and Leslie 
G. Christie, Jr. 



«■■ HE MECHANICAL DESIGN of the autoi hanger 
mechanism for the HP Series 6300 Model 20CB/A 
rewritable optical disk library system posed sewr.d 
technical challenges, including architecture, reliability, 
physical size, and schedule. The system holds 32 optical 
disk cartridges and has two magnetooptical disk drives, 
The magnetooptical disks are rewritable. Each cartridge 
holds 650 Mbytes of data; however, only 325 Mbytes is 
accessible a1 a lime because the drives are single-sided. 
The total capacily of the library system is 20,8 Ghytes, The 
system runs on a single-ended SCSI asynchronous bus, 
which conforms to the SCSI II standard established for 
autochangers. The average access time to load a disk from 
a storage position to a drive is seven seconds. 

The mechanical architecture of the autochanger excludes 



any electrical components, cables, or connectors on the 
moving parts of the mechanism. This ''passive payload" 
concept was chosen to maximize product reliability. The 
design team set a goal at the unset of the project In have 
an absolute minimum of sensors, solenoids, and motors. 
The final design has only two motors, no solenoids, and 
three optical sensors. The sensors are used in the vertical 
calibration of the system and in the mailslot. 

Physical size was determined early in the product design 
to allow use in two orientations- In the normal orientation, 
the autochanger fits into an HP rack. It can also be laid on 
its side and used in an industry-standard 19-inch rack. 
This Iwo-urienEatiun requirement established the height, 
width, and depth of the product. Meeting these space con- 
straints was a persistent challenge in the design of the 
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Fig. 1. Mechanical layout of the 
HP Series 6300 Mode! 20GB/ A re- 
writable optical disk library system 
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subsystems. 

Adding to these design challenges were the need to en- 
sure HP quality and the time constraints of an aggressive 
schedule. 

Fig. 1 shows the mechanical layout of the autochangen 

Mechanical Functions 

There are two basic mechanical functions of the pro* i 
First, the user can load or remove a cartridge via the 
mailslot. Second, the cartridges are moved fnmi storage 
slots and the mailslot to drives and vice versa via the picker 
mechanism. These functions are implemented using two 
motors and associated subsystems. All movement in the 
product has been grouped into two types: Y or vertical 
motion and Z or horizontal motion, 

Y Motion, All movement tip and down along the vertical 
ways is labeled Y motion, It is driven by a dc servo motor 
and a vertically mounted leadscrew. A small toothed bell 
drives the vertical leadscrew through a reduction ^ *8$ Ole 
vertical carriage is attached to the leadscrew. 

The vertical carriage is made up of the horizontal car- 
riage, picker, and translate mechanisms. All of these mech- 
anisms are powered by a toothed belt called the T belt. 
Z Motion. The Z or horizontal plane is the plane in which 
the following motions occur; 

■ Plunge* The picker plunges to get a cartridge from a drivr 
or slot or to put a cartridge into a drive or slot. The picker 
is the cartridge carrier, that is T the device that holds a 
cartridge that is being moved between a storage slot and 
a drive. 

■ Flip, The picker is caused to rotate 180 degrees. 

■ Translate. The system has two stacks of cartridges. In a 
translate move, the Y and Z systems are positioned to 
move the picker and the horizontal carriage — on which 
the picker is mounted — from stack to stack. Translate 
motions occur only at the lowest vertical position ol &e 
vertical carriage, 

■ Mailslot Actuation, This is a special plunge with picker 
side and vertical positioning, 

All Z motion occurs within or as part of the vertical 
carriage. AM Z motion is driven by the T hell, which is 
attached to the Z motor and oriented perpendicularly to 
the vertical carriage assembly. 



The plunge occurs in the picker mechanism. This motion 
i ven by the T belt through a gear attached to the picker 
leadscrew. The flip is required because the disks are double- 
sided and the drives are single-sided. The translate occurs 
through a special combination of Y position and release 
mechanisms on the vertical carriage. When all of the proper 
conditions are met the Z motor will drive the horizontal 
carriage from one stack to the other (vfailslol 
occurs at a particular vertical height, sensed by maltng 
actuators on the picker mechanism and the mailslot. When 
all of the proper conditions are met a plunge motion of the 
picker actuates the mailslot. 

Vertical Carriage 

As described earlier, the cartridge holder (picker] must 
be able to move in the vertii al direction to any magazine 
or drive slot. It must also be able to move to one of the two 
horizontal positions. The vertical carriage is the mecha- 
nism that constrains these motions. It is designed to hold 
the end of the cartridge holder in close tolerance despite 
variations of the sheet-metal structure that forms the enclo- 
sure lor the prod in t nmi to which all of the other parts are 
mounted and referenced, The vertical carriage is light in 
weight to reduce dynamic Fori e£. fl is designed to he installed 
and removed easily and to have a high degree of reliability. 
The biggest challenge in its design proved to be designing 
it to fit into a 375-mm box structure. 

The vertical carriage is shown in Fig, 2. It is guided in 
its vertical motion by a set of angled rails, which attach to 
the structure, as shown in Fig. 1 . The vertical carriage con- 
sists of: 

■ A set oi bearing blocks with roller bearings, which roll 
on the i\h! ■■ 

■ Plastic carriage blocks, which hold the bearing blocks, 
the T belt pulleys, and the horizontal rod and way 

■ The horizontal rod and way. which provide the translate 
means lor the horizontal carriage and picker. 

In the breadboard design, a 0, 7 5- in r:h -diameter rod and 
a linear bearing wen: used For the vertical transport. How- 
ever, because of the volume limitations, this design proved 
difficult to implement. To solve this problem and meet 
manufacturing requirei nen Is. the rail and roller bearing ap- 
proach was chosen. The main problem this design faced 
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Rg« 2. Vertical c am age s ttu cture. 
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Fig. 3. Horizontal carnage and 
picker mounted on the vertical 
carnage. 



was the variations of the sheet-metal structure. To account 
far these variations, the right-side bearing blocks are con- 
strained in the carriage block but are spring-loaded (float- 
ing) between the vertical rail and the carriage block. This 
allows the assembly to correct tor tig to a millimeter of 
structure variation and still maintain the reference against 
the left rail t winch always serves as the vertical reference 
surface* 

A steel bearing block linkage is used to stiffen the vertical 
carriage assembly relative to the vertical rails. The bearing 
block linkage ties the two floating bearing blocks together 
to ensure that I heir motion always acts to tighten the ver- 



tical carriage within the vertical rails. 

Because of the limited volume, the left-side rail has to 
perform several functions. Half-inch holes in the bottom 
of the extruded aluminum rail provide for mounting the 
bearings and shaft. This assembly has space for gearing in 
the back and the drive gear for the T belt in the front. At 
the top. a quarter-inch slotted hole in the rail and a plastic 
slider that fits around it provide a belt tensioner. The top 
T belt idler pulley is placed through the slider and rail, 
and is spring- loaded upwards to provide proper belt ten- 
sion. Because the belt places a moment an the slider, it 
will lock up when momentary high forces are encountered. 




Translate Bar 
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Fig, 4, Translate mechanism. 
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This keeps the belt from slipping when the drive system 
encounters the high force spikes sometimes seen during 
::. gazine and drive insertions. 

The bearing blocks provided several design challenges. 
The first problem was running the bearings on the 
aluminum r, is very noisy and caused the 

aluminum to wear. Plastic tires were placed on the bear- 
ings, but developed flat spots in storage temperature test- 
Ing. Plastic with better creep qualities was tried, but 
show lures short of the required life. 

Foi the final design, the plastic is Delrin and the tires 
are redesigned to increase their surface contact area. The 
bearing blocks were originally designed to be made of 
aluminum, but the aluminum tended tu gall while sliding 
in the carriage blocks, and was much higher in cost than 
initially expected. Therefore, an all-plastic design was con- 
ceived, using bearing blocks made of polyphenylene sul- 
fide with 40% glass. This design works much better. It 
results in lower friction. lower wear, better tolerances be- 
tween mating parts, and a significant cost savings. 

The carriage blocks lie the horizontal rod and way to- 
gether structurally, hold the T belt pulleys, and provide 
the sliding constraints for the bearing blocks. Glass-filled 
polycarbonate helps reduce the carriage blocks' weight and 
cost. Because the carriage hi ricks are I he stops for translate 
motions of the horizontal carriage, the distance between 
the blocks is set by machined features in the horizontal 
rod and way. which are held securely in place by crush 
bumps in the plastic blocks and then bonded for added 
rigidity. Once the vertical carriage is installed between the 
side rails, the carriage blocks cannot separate. 

The horizontal rod is a three-eighths-inch hardened 
stainless-steel rod. The horizontal way at the bottom of the 
vertical carriage is a machined aluminum L-section bar, 
The top of the I n Hon is a track for roller bearings on 
the horizontal carriage and the bottom of the L section 
provides a latch that holds the horizontal carriage in the 
appropriate translate positions, The aluminum way also 
provides a mount ing surface for a portion of the translate 
lock assembly. This way was original ly to he extruded, but 
the added machining made this less cost -effective than a 
completely machined pEirl. 

Horizontal Carnage 

The horizontal cai-ridgr supports the picker and trans- 
lates it from one cartridge stack to the other. The support 
structure for the horizontal carriage allows linear motion 
in one axis while excluding linear motion in two axes and 
rotational motion in three axes. A rigid structure is neces- 
sary to ensure proper alignment of the picker tor cartridge 

exchanges, 

The hurizimtal carriage is supported by I he following 
parts of the vertical carnage: the horizontal rod. I lie hori- 
zontal way, the two carriage blocks, the four bearing blocks, 
and the bearing block linkage on the spring-loaded [right] 
side. Fig, 3 shows the horizontal carriage and picker 
mounted on the vertical carriage. 

A machined aluminum casting controls picker alignment 
and serves lis a mount ing surface for the flip support 
translation lock assembly, the hub lock assembly, two idler 
shafts, two bearings lor the main picker shaft, two lire 



shafts, and two linear bearings for translation capabilities, 
Rigidity and spatial concerns top the list of design require- 
ments. 

The hardened, ground, steel horizontal rod supports the 
horizontal carriage linear hearings. Two tires on roller bear- 
ings, mounted beneath the horizontal carriage, ride on the 
front and rear surfaces of the aluminum horizontal w 
bar] to control rotation about the rod. 

Translate Mechanism 

The translate motion — BM3 - rom one side 

of the autochanger to th^ other— requires a combination of 
the vertical and horizontal motions. There were six design 
goals for the translate mechanism. First, in line with the 
passive pay load concept, the movement must only use the 
two servo motors and require no additional sensors or sole- 
noids to clutter a tlean and reliable design. Second, the 
mechanism must be reliable to one million cartridge ex~ 
changes. This requires ti Iranslate mechanism life of 1.5 
million translates because, on the average, there are 1.5 
translates per exchange. Third, no more than 6 mm of V 
motion can be used to actuate the translate mechanism. 
Fourth, the design must minimize wear through proper 
selection of materials and geometry. Fifth, the design musl 
be fault tolerant. This fault tolerance must include the abil- 
ity to recover from power failures at all limes, Sixth, the 
design must allow trans [tiles ai both I lie top and bottom 
vertical positions to provide architectural flexibility, al- 
though in the current product, translates only occur at the 
bottom. 

The translate mechanism [sec Fig, 4) consists of the ver- 
tical carriage including the horizontal carriage and the hori- 
zontal Way with adjustable stops, and the Iranslate lock 
mechanism. The translate lock mechanism [Fig. 5) consists 
of: 

m A translate lock arm, whit ,h pivots in and out of a slot 
in the vertical carriage's horizontal way 

■ A hublock, which can engage a notch in the picker hub 
to prevent the hub from rotating 

■ A translate bar fixed m the strut lnn.% which pushes the 
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Fig, 5. Translate lock mechanism. 
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lock open. 

Both ihtf Iranslate lock arm and the hub lock are mcLinted 
on I he horizontal carriage, They are independently spring- 
loaded downward for the normal case of the horizontal 
carriage bein^ locked In place and the plunge motion al- 
lowed* 

The translate lock mechanism has to hold the horizontal 
carriage rigidly fixed normally, and ensure that only one 
motion at a time can occur, either translate or plunge. En- 
suring only singular motion is necessary because there are 
no sensors to tell Ihe system what the picker and horizontal 
i ;i triage are actually doing, so the servo could conceivably 
gttl "lost" without this stipulation- Pig. 6 shows the two 
basic locked positions: plunge allowed and translate pre- 
vented or translate allowed ,jrnl plunge prevailed. 

The translate lock arm pivots on a horizontal axis con- 
tained within the horizontal carriage. The translate lock 
arm is spring-loaded to pivot downward, which forces the 
arm into a slot in the horizontal vvav and locks the horizon- 
tal carriage, and therefore ihe picker, to one side of the 
vertical carriage or the other To minimize wear from the 
sliding motions, the translate lock arm has a needle bearing 
on its far end for contacting die translate bar and a molded 
wear pad closer to the center thai con tat Is Ihe hub Jock. 
The translate bar is rigidly attached to the sheet -metal struc- 
ture and is the contact surface that actuates the translate 
lock arm. The hublock is another downwardly spring- 
loaded, pivoting arm that is responsible for locking the hub 
when actuated by con lac I wilh Ihe translale lock arm. The 
hub is part of the plunge mechanism so that locking the 
hub results in locking the plunge mechanism. Locking the 
hub locks the horizontal carriage to the T bell so Ehat the 
Z servo can move the entire horizontal carriage instead ot 
just actuating the plunge motion. 

The translate movement can best be described if split 
inlo four phases. In phase 1. the Z motor lines up a slot in 
the hub with the hublock, allowing for its eventual inser- 
tion. The Y servo lowers the entire vertical carriage assem- 
bly, causing the translate lock arm to contact and he pivoted 
upward by the translate bar. The translate lock arm in turn 
contacts the hublock, moving the hublock into the hub slot 
and locking the hub and the plunger, At the end of phase 
1. both the plunge and translate motions are locked. This 
overlapping of the two locks is a reliability feature that 



prevents the Z servo from hfeivfieeling and losing track of 
where the picker is, The servo is always in positive control. 

In phase 2, when the hub is securely locked, the Iranslate 
lock arm is lifted free and clear of the stops on the horizontal 
way lo allow the Z servo to translate the horizontal carriage 
across I lie vortical carriage. Phase 2 is completed when the 
V s#tfO saturates* as a result of the vertical carriage's hitting 
the hard stop of the translate bar at the bottom of the struc- 
ture, thus ending I he vertical movement, No sensor is re- 
quired to end ihe verHi al movement, thus contributing to 
reliability and simp] icily. 

In phase 3 T the V servo is stationary while the Z servo 
drives the horizontal carriage from one side to the other. 
The needle bearing on the translate lock arm rides on the 
translate bar. This allows the tab on the translate lock arm 
to clear the horizontal way along the entire path, The design 
has to be tolerant of a possible power failure, since it would 
be very easy to gel into an unrecoverable position at this 
time. To this end. the Iranslate lock arm geometry is such 
that if the vertical carriage rises, as it would after a power 
failure, the Z servo can still pull the horizontal carriage lo 
one side and have the tab on the translate lock arm lock 
inNi the stop. This is another major reason why the hublock 
and the translate lock can never physically be unlocked at 
the same time, even in the worst-case tolerance conditions. 
Phase A ends with the Z servo saturating with the horizontal 
carriage against the opposite side of the vertical carriage. 
thereby finishing the translation part of the move. 

The Z servo continues to saturale throughout phase 4 t 
while the Y servo moves the vertical carriage upward. This 
movement allows the translate lock arm to drop into the 
beveled stop in the horizontal way T which locks the hori- 
zontal carriage. The hublock does not follow the translate 
lock arm downward hecause it is held in place through 
friction by the saturating Z servo. This ensures that the 
horizontal carriage is in direct contact with the side, allow- 
ing reliable locking of the translate lock arec A bevel in 
the stop eliminates the possibility that any burr in the lock 
arm will cause it to hang up. The stop is adjusted during 
assembly to ensure that the horizontal carriage does not 
float sideways in the locked position. When the vertical 

*SeivD saluraTion means thaune Torque ouipui of hie servo motor, which is calculated from 
Ihe malar voliage and the motor sorque constant, has exceeded a ihreshald Servo -r-v 
%s asso called torce sense ot touch 
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Fig- 6, (a) Translate lock arm 
locked into horizontal way. Plunge 
motions allowed, (b) Hublock arm 
locked into picker hub Translate 
motions allowed — no plunge mo- 
tions. 
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ige has moved vertically far enough to allow the needle 
bearing on the translate lock arm lo separate from the trans- 
late bar, the Z servo comes out of saturation and allows 
the hublock to fall back down onto the translate lock arm. 
The translate move is now complete, freeing the auto- 
changer to perform whatever other moves are w | 

Picker 

Like the rest of the antochanger t the cartridge retre 
mechanism is designed with simplicity in mind to help 
meet both reliability and cost goals. The mechanism re- 
quires four degrees of motion within a small form Factor: 
lei nut plunge, grasp/release cartridge, side-to-side trans- 
late, and ISO-degree flip. In spite of all the motions, it was 
fell that the picker had to have a passive payload. that is T 
no motors, solenoids, or sensors on t he moving platform, 
for the highest possible reliability, 

Fig, 7 shows the basic layout of the mechanism. It con- 
of six main components or subassemblies: 
■The vertical carriage, which connects to the vertical 

leadscrew, providing the up/down motion 

■ The horizontal carriage, which holds the cartridge picker 
mechanism, flip latch, and translate lock arm, and trans- 
lates from side to side 

■ The picker hub, which converts the belt motion to picker 
plunge motion 

■ The picker itself, which can grab and hold a cartridge 

■ The translate lock mechanism, which either holds the 
horizontal carriage fixed or allows it to translate from 
side to side 

■ The flip latch mechanism, which holds the picker flat 
during plunges but can allow the picker to be Sipped 
180 ii- 

The picker hub is a single p las lie mnhh-'ri piece with 
three functional sections. Tin: back portion is a pulley, 



Picker 




which the belt from the motor engages to provide ail the 
power to the horizontal carriage and picker. The front is a 
gear, w T hich mates with a smaller gear on the end of the 
picker's leadscrew to convert the belt motion to p 
plunge motion. Finally, the center section has two cutouts 
180 rjart which are used by the translation latch 

h k the hub. The belt is the only power source for the 
entire picker mechanism, and the encoder on the motor 
moving the belt is the only method of sensing anything on 
the horizontal carriage. 

The picker mechanism design was heavily influenced 
by space constraints. The width of the sheet -metal structure 
limited both picker width and picker height [because of 
Dips), Short structure-length constraints and long mini- 
mum plunge depth requirements necessitated a compact 
cartridge grasping mechanism, In addition, the front-panel 
openings in the magnetooptical drives limited where the 
picker could grab the cartridge and required that whatever 
inserted the disk had to go well past the drive front panel. 
Another concern was how to handle misalignments, par- 
ticularly as the cartridge was loaded into the drive. 

With these concerns in mind, the picker was designed 
to mimic a hand pushing a cartridge into a drive, "Fingers" 
grab the cartridge from either the drive or a magazine, and 
the "thumb" pushes the disk back into place. The 
[eadscrew + s nut Qoais within ihe thumb, providing the 
muscle. (The nut is not rigidly attached in the thumb to 
allow for leadscreu runout and general part variations.) 
The finger mounts into the thumb, which in turn rides in 
a plastic shell that has tracks to guide the finger to grab or 
release the cartridge. Identical thumbs, fingers, and shell 
h lives are used DO both sides to form the whole grasping 
mil hanisui. Fig. 8 shows the two paths the fingers can take 
depending tm their inilial position. The fingers are spring- 
loaded to a normally rotaled-in position. When the fin 

Vertical Carriage 




Flip Latch Mechanism 



Fig. 7. Cartridge retrieval mechanism 
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Fig. 8. Picker finger and thumb 
mechamsm. 



move out and contact the cartridge, they are splayed out- 
ward and grab the disk. In the track, a one-way gate turns 
the system into a type of mechanical flip-flop. This gate t 
a molded spring, is forced downward as the finder travels 
over it from the drive side, but will nut move down when 
the fingers come from tin: picker side. Thus, will] I fie next 
plunge, the fingers must follow the release path and are 
rotated out to release the cartridge. The center of the thumb 
then pushes the cartridge to its final position. As the thumb 
retracts, the fingers spring around again to their normally 
closed position, ready to grab a cartridge on the next plunge. 
Materials were an interesting challenge in the picker de- 
sign. The one-way gate is made of Ullem, which h&S high 
strength, good wear qualities, and low creep — important 
characteristics for a preloaded, highly cycled spring. The 
fingers, thumbs, and sleeves all require low-wearing mate- 
rials, and since these parts slide against each other, each 
has to be of a different material The fingers also require 



high strength, so they are made of 35% long glass, 15% 
Teflon polycarbonate. The thumbs have the most parts slid- 
ing against them (leadscrew nuts, sleeves, and fingers] and 
inquire good ilalness, so they are molded of 30% glass. 
15% Teflon Nylon 6/10. The sleeves, w r hich ate pari of the 
Hydrostatic discharge path for any charge that might build 
up on the picker and affect the cartridge, are molded of 
10% carbon, 15% Teflon polycarbonate. 

Flip Mechanism 

The objectives in designing the flip latch mechanism 
were to use already existing motion and to limit the flip 
lo 1(10 degrees. Using the rotation of the picker hub without 
moving the leadscrew satisfies ihe first objective, and smart 
hard stops satisfy the second. Kig. 9 shows the main parts 
of the latch: the pivot arm, the release arm T and the cam. 
In normal picker plunge motions, a nib on the rear of the 
picker shell is trapped between the pivot arm on the bottom 
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Fig. 9. Ffip latch mechanism. 
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and the cam nn the top. This keeps the picker flat with 
respect to the drives and magazines. Fig. 10 shows the 
steps involved in opening and closing the lock during a 
flip. To flip, the thumb plunges backwards, pushing the 
release arm, which is mounted on the pi vol arm. Although 
the release arm can rotate dowm the pivot arm, the 

thumb, pushing backward on the release arm. forces the 
il arm to rotate backward also, allowing the nib to fall 
down through. As the belt continues to rotate the hub. the 
picker's leadscrew bottoms out when the thumb can move 
back no farther. Thus the entire picker rotates with the 
hub. As soon as the nib has cleared the pivot arm, the arm 
springs back to its normal position. At the end of the flip, 
the nib from the other side comes around, opens the cam, 
and is stopped by the pivot arm. The thumb, which origi- 
nally pushed the release arm backward, now pushes it 
down. With the release arm down, (lie picker cannot flip 
again until the lock is rearmed. I hat is, until the thumb 
plunges out far enough to allow the release arm to spring 
back up again. 

Stress loads, space, tolerance build-up, and fail-safe 
once-only actuation were the major concerns in the design 
of the flip mechanism. Long fiberglass material in both the 
cam and the pivot arm gives the parts superior wear and 
impact strength. The orientation of the latch parts not only 
economizes space but puts the impact loading down onto 
the pivot shaft for minimal bending stresses. The cam al- 
lows for variations in parts and any wear in use while 
maintaining the picker fixed during plunge operations. The 
back side of the release arm is designed to help prevent 
accidental double flips. When the release arm is rotated 
just slightly, the back no longer aligns with a through hole 
in the lock's support bracket This prevents the pivot arm 
imm rotating and eliminates the possibility I hat the impact 
at the end of t&e 'flip mighl emise tMflip lalchloopena^ain. 

Mailslot 

The mailslot is a mechanism that allows the user to install 
a cartridge in the autochanger just as if il were being put 
into a drive. For the picker to grab the disk cartridge, the 
mailslot mechanism must rotate the cartridge 180 degrees. 

The part of the mailslot that accepts and delivers car- 
tridges is called the carrier. In the out position, the carrier 
extends the cartridge approximately 20 mm out from the 
front panel for ease of removal by the user. When a cartridge 
is installed and pushed flush with the front panel, a spring 



mechanism catches, giving the user a stop position. As this 
position is reached t a sensor trips, indicating tha* 
mailslot has a cartridge installed. T; i then moves 

to the correct height to activate the mechanism. Using the 
picker to activate the mailslot eliminates the need for 
another motor in the system. 

The mailslot rotates the cartridge using forces applied 
through the picker and an actuator (see Fig. 11). The ac- 
tuator is approximately at the center of mass of the cartridge 
and the carrier, thereby keeping the forces in a straight 
line. The leadscrew nut on the picker drives the actuator. 
The actuator and the carrier run in tracks molded into the 
top and bottom pieces of the mailslot. The tracks are de- 
signed so that as the actuator drives the the carrier from 
front to back in the mailslot, the carrier is rotated 180 
degrees. 

The cartridge load sequence consists of the follow ing 
moves; 

1. User pushes load button 

2. Move picker to mailslot actuate height 

3. Plunge to maximum get position 

4. Check for sensor sensing cartridge in mailslot 

5. Rotate mail in 

6. Move to gel -mail heighl 

7. Plunge to get cartridge 

8. Pull cartridge into picker 

9. [Sequence of moves to put cartridge into drive or mag- 
azine] 

10. Move to mailslot actuate height 

11. Rotate mail out. 

When the carrier is facing the inside of the autochanger, 
it looks like another magazine slol lo the picker. When the 
carrier is facing the outside it looks like a drive to the user. 
A special catch mechanism between the actuator and the 
mailslot top keeps the carrier from moving when either the 
user or the picker is pushing or pulling on the cartridge, 
but allows the carrier to be rota led and moved when the 
picker is pushing or pull ing on the actuator. In other words, 
the carrier has limit positions on both sides of the mailslot, 
and the actuator must be the moving device to move the 
carrier past these limit positions. 

Because the carrier slides in die top and bottom pieces 
of the mailslot, the wear of the carrier against these parts 
require I special materials considerations. The carrier and 
m tuator needed (n be different from the top and bottom, 
but all parts were to be molded. For regulatory reasons, all 
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Fig. 10. Flip latch operation, (a) Initiation of flip- Thumb pushes release arm. (b) Start of flip 
Picker falls through, (c) Start of cam opening (d) End position of flip. Release arm cocked 
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of the materials had to be self-extinguishing when exposed 
to flame The top and bottom are made of polycarbonate 
with glass and Teflon fillers. Polycarbonate is used because 
of its low cost, since these are the two largesl parts. The 
Teflon (PTFE) is put in for friction reduction. The glass is 
added because the parts need to be flat and strong enough 
to hold the whole assembly while the user or picker pushes 
on (he mechanism Irom either side, A special milled glass 
fiber was chosen as a filler because it tends to produce 
flatter parts (±0.2 mm across the part) and adds the required 
stiffness. The carrier and actuator are both molded out of 
poly ethers ulf one (PES] with Teflon filler, PES has several 
characteristics that are needed in the part design. It is very 
dimensional ly stable material. The PES and polycarbonate 
materials wear against each other very well, PES can be 
color matched to the custom color required by HP, Also, 
PES can be ultrasonically welded. The carrier is approxi- 
mately 120 mm deep over a section 11 mm high, Molding 
this would be very difficult if not impossible, so the carrier 
is made in two pieces and the two are welded together. 

To assemble the mailslot. all parts are either added to 
the top half of the enclosure or placed directly into the 
bottom half. The top and bottom are then screwed together, 

Magazines 

The four magazines in the HP Series 63(H) Model 20GB/A 
rewritable optical disk library system each hold eight mag- 
netooptical disk cartridges [Fig. 12). The magazines must 
hold the cartridges in position for the picker to remove and 
replace them without too much force, but they must also 
hold the cartridges while the machine is physically moved. 
The magazines are designed so that referencing and align- 
ment are correct when lhi\ assembly is inserted into the 



struct me. 

The alternative of molding the magazine assemblies in 
one part was ruled out because of schedule r onstraints and 
tooling costs. Minimum wear on the cartridge contact sur- 
faces required a plastic part, and for ease of assembly we 
use a sheet-metal mating part. The entire magazine assem- 
bly uses only three parts: a plastic part used four times, a 
sheet metal part used twice, and a plastite screw used eight 
times. Details needed for holding the cartridges are easily 
created in the plastic part. Sheet metal is an inexpensive* 
and effective way of holding the plastic parts together and 
referencing them into the structure, 

The plastic guide in the magazine assembly is made of 
polycarbonate with 10% PTFE (Teflon) and 10% aramid 
ik> viai) fibers. The Teflon is added for friction reduction. 
Testing during product development showed that the stan- 
dard cartridge case made of ABS wore too easily against 
^vi ii the Iuhricaletl guide, so the cartridge cases were 
changed to polycarbonate. Extensive testing has shown 
making both the cartridge case and the guide of polycarbo- 
nate is acceptable because n I the lubrication in the guide. 

The aramid is an additive for dimensional stability. Dur- 
ing molding, the aramid ensures that the part shrinkage is 
the same in both flow directions. This keeps the plastic 
guide stable in all of its required referencing tasks. The 
cartridge is spaced and held vertically by the guide. The 
catch details for holding the cartridge are molded into this 
part and close tolerances are needed for a proper snap fit. 
The plastic molding process allows a design that lowers 
insertion force hut keeps the removal force at desired levels. 
Kig. 12 shows the cantilever spring and cartridge snap de- 
tails. 

The autochanger is designed lor a million extlianges. 




Fig, 11, Maitsfot assembly. 
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Fig. 12. One of the four eight- 
cartridge magazines Cantilever 
springs and snap details to hold 
the cartridges are molded into the 
plastic Side parts of the maga- 
zines. 



Therefore, the springs designed into the guides must have 
a long fatigue life. The Kevlar is helpful in this area, but 
not as milch as fiberglass would be. A trade-off of dimen- 
sional stability for part strength and therefore fatigue life 
was made in the choice of materials, This trade-off has 
required testing to ensure that I he spring life is a I least 
150,000 cycles per spring. Considerable E&Sttng hits estab- 
lished that the part meets the requirement. The can! i lever 
springs are designed for constaul stress over their entire 
length, 

The sheet-metaJ pail is a horizontally symmetric part 
that holds the plastic parts together and allows easy instal- 
lation of (he assembly into the structure. This part is folded 
such that the side plastic parts are accurately located with 
respect to the reference surfaces on the sides of the struc- 
ture. This reference scheme keeps the tolerances between 
the magazines and other critical elements lu a minimum. 
Once the magazine assembly is built, it can only be installed 
correctly into the machine. Hard -tooling of the sheet-metal 
pari reduced magazine location errors and improved per- 
formance of the unit during of the course of testing and 
design. 
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Optical Disk Autochanger 
Servomechanism Design 

A "sense of touch" and error recovery routines contribute 
to reliability. Data capture, error injection , and mechanical 
regression testing facilities improved the productivity of the 
designers, 

by Thomas C, Oliver and Mark J. Bianchi 



THE SERVOMECHANISM OF THE HP Series 0300 
Model 20GB/A rewritable optical disk library system 
is a collection of electronics and firmware algorithms 
that control the autochanger mechanism, The servo pro- 
vides (he muscles and brains that bring the mechanical 
limbs to life. Muscles are provided using motors, power 
supplies, and sensors. The brains are contained in the 
firmware program that controls how the muscles are ener- 
gized. 

It is the responsibility of the servo to control the auto- 
changer mechanism reliably. Designing for reliable control 
requires that many aspects of the system be analyzed and 
optimized, The design encompasses a broad range of en- 
gineering disciplines, including system models for stability 
and performance, continuous and discrete- time control 
theory, firm ware architecture, motor parameter optimiza- 
tion, analog hardware design, and digital logic design. 

Goals and Solutions 

The goals for the servomechanism design were high re- 
liability, flexibility, system stability, high performance, 
user safety, and contributions to other parts of the develop- 



ment effort. 

Techniques for achieving high reliability Include the 
sense of touch for adaptive, gentle movements, minimizing 
the number of components through firmware integration, 
the use ol proven, reliable technologies [HP ICs, standard 
LSI. surface mount technology], increasing hardware de- 
sign margins by overrating, and the use of self-calibration, 
error detection, and recovery techniques. 

Flexibility is provided by firmware implementation of 
servo functions, a modular design architecture, and the use 
of a high-level programming language. 

System stability is ensured by extensive system modeling 
before and during implementation, optimized programma- 
ble compensation for each movement, and margin verifica- 
tion over all operating ranges. 

High performance is achieved by optimal compensator 
selection for each movement, motor and power supply op- 
timization based on the performance model, and overlap- 
ping of movements. 

User safety is ensured by continuously monitoring 
applied forces in firmware and hardware, 

Contributions to the development project outside the 
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Fig, 1, Servo hardware sre^ lec- 
ture of the HP Series 6300 Model 
20GB/A rewritable optical disk 
library system. 
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servo area include a data capture system. mechanical re- 
gression tests, error injection, and code that can be lever- 
aged by other projects. 

Design Philosophy 

Extensive modeling was performed before the design vva.s 
implemented. A performance model was developed so that 
motors, gears, and power supplies could be selected to 
meet the swap time goal. Plant models and compensator 
techniques* were simulated so that optimal control 
schemes could be investigated. Bandwidth analysis was 
required to ensure thai a microprocessor could close the 
control loop I >*gh, Root locus and Bode analysis 

methods were vital tools used to ensure adequate stab 
margins. 

Proven, reliable HP technologies are employed in the 
servo design. Digital implementations were selected over 
analog techniques because they offer greater flexibility and 
fewer components, A custom digital IC I mm the HP 
DraftPro plotter family is used because it has a proven track 
record and is used in large volumes. HP optical encoders 
were a natural choice based on their exceptional reliability 
and manufacturability. A power driver from the HP 7 980 A 
tape drive is also used. Design margins were increased on 
all critical components, particularly the devices that dissi- 
pate large amounts of power. Additional reliability is 
achieved by sharing a single microprocessor between the 
servo and interface functions. 

The servo firmware architecture contributes to HP Series 
6300 Model 2 0GB/ A reliability on many levels. The firm- 
ware is designed to provide maximum integration of servo 
functions such as closed-loop control, profile generation, 
and error detection, Firmware integration helps reduce 
parts count and increase flexibility, A "sense of touch" 
technique was developed to eliminate the need for sensors 
on the moving transport, a key contribution to reliability. 
Control of each mechanical function (vertical movement, 
flip, translate, I/O) is tailored to provide gentle, adaptive 

*A plan! model is a ccnirol theory model of the device be<r*g controlled. Compensator 
techniques are methods ot stabilizing the conTro* system 



movements. Self-calibration, error detection, and error re- 
coverv play key roles in increasing reliability and manufac- 
(inability, 

Another project philosophy was to increase the produc- 
tivity of the design team through the creation and u- 
tools. Features such as data capture, error injection, and 
mechanical regression tests are incorporated into the 
firmware to give the design engineers a "mechan' 
loscope" for the mechanism* Our investment in networked 
HP 9000 workstations provided a common development, 
debug, and testing platform for the design team 

Hardware Architecture 

The servo hardware is kept to a minimum to ensure 
reliability. Digital circuitry is used whenever possible be- 
cause it usually requires fewer parts and is more flexible 
than analog implementations. Real-time functions, which 
caul be performed in firmware, reside in hardware. These 
functions include the motor drivers and the motor position 
encoding. Fig. 1 shows the servo hardware architecture. 

The motor driver consists of pulse width modulator 
and an H-bridge amplifier. A custom HP ASIC (application- 
specific IC) is used to generate a PWM [pulse width mod- 
ulation] signal for two motor drivers configured for bidirec- 
tional operation. The IC contains a register that is used to 
transform a digital value into a TTL PWM signal having a 
dutv cycle proportional to the register value. A state se- 
quencer PAL (programmable array logic) transforms the 
IC's outputs into lour tiine-sequenced signals that control 
operation of the FET H-bridge. The PAL prevents CTOSS 
conduction in the FET H-bridge and offers a flexible alter- 
native to analog time delay circuits. The FETs amplify the 
sequencer outputs and present voltage pulses to the motor. 
The motor averages out the high-frequency pulses and re- 
spoods as if a dc voltage were applied at its inputs. 

As I he motor turns, its Iwodiannel shaft encoder sends 
a series of pulses to the HP ASIC. Quadrature decoding is 
performed by the ASIC, and a register representing the 
motor position is made available to the system. Thus, the 
firmware uses the ASIC as a single interface with which 



SCSI Bus 



SCSI 
Controller 



Command 
Processor 



Mechanism Commands 
and Status 



Front Panel 



Front-Panel 
Controller 



Mechanism 
Control 



Servo Commands 
and Status 




Part of the 
Servo Function 



Servo 
Control 



To From 

Hardware 

(Motor Control IC) 

w ► 



Fig. 2. Top-level firmware ar- 
chitecture. 



DECEMBER 1990 HEWLETT-PACKARD JOURNAL 25 



)Copr. 1949-1998 Hewlett-Packard Co. 



to control the motor voltage and receive positional feed- 
back. 

Firmware Architecture 

II ie servo firmware is partitioned into two types of code: 
real-time and nonreal-time. Real-time firmware is referred 
to as servo code while noiireal-time firmware is called 
mechanism code. Servo code is responsible for the closed- 
loop operation cil the system. Real-time code is placed in 
an interrupt routine, which executes once every milli- 
second. Mechanism operations are coordinated by the 
mechanism code through control of the servo code, The 
two processes communicate through a sel of primitive 
routines, which manage the flow of commands and state 
information. Fig, 2 shows the overall firmware arch i lee lure 
and Fig, 3 shows the servo firmware architecture. 

Servo Code 

The servo code is responsible for closed -loop compensa- 
tion, profile generation* sense of touch calculation, error 
detection and shutdown, and development lools, 
Closed -Loop Compensation. Closed-loop compensation is 
the algorithm that determines how the motors respond lo 
command position changes or payload disturbances. Com- 
pensation is implemented with a simple P-D (proportional- 
derivative) algorithm, It can be described by the following 
equation: 

pwm = K 1 (e - K 2 ojJ t 

where pwm is the command voltage to the PWM on the 
motor control ASIC t e is the motor's position error, oj is 
the motor's angular velocity, K 1 is the proportional gain 
(stiffness), and K 2 is the derivative gain. 

Since each mechanical function has a different load 
characteristic, the servo gains must be adjusted for each 
mechanical operation- Knowledge of the load is maintained 
by the mechanism code, which controls these gain values. 
Profile Genera lion. The method used to change the motors' 
position from point (Y^Z-,) to point (Y^Z 2 ) is referred to 
as profile generation. Profile generation is the creation of 
a series of command positions to the Y and Z compensators 
that will cause the motors to move a desired distance. A 
trapezoidal velocity profile is generated based on parame- 
ters of cli stance t acceleration, and peak velocity, Scaling is 
also performed to allow the motors to move different dis- 
tances at different speeds simultaneously. 
Sense of Touch Calculation. The servo code is responsible 
for determining the forces being exerted by each motor/load 
system. Forces are monitored by the servo and mechanism 
firmware to obtain an additional form of feedback from the 
mechanism. During each interrupt, the servo calculates 
force using an equation based on motor voltage and veloc- 
ity- The equation is: 

f = K 5 pwm - K 4 oj t 

where f is the applied force, pwm is the command voltage 
to the PWM on the motor control 1C, w is the motor speed, 
and K A and K 4 are constants based on the motors and gear- 
ing. Traditional techniques use direct current measure- 
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merit, which involves added circuitry and cost, 
Error Detection and Shutdown, Error detection is an impor- 
tant safety and reliability feature of the servo code. During 
each interrupt » the servo firmware monitors the forces, volt- 
ages, and currents of both motor systems to determine if 
an error condition exists. Measured values are compared 
against expected thresholds for a given submove* The 
mechanism control code tailors the threshold for each sub- 
raove within a mechanical operation. If limits are exceeded, 
the servo will immediately disable motor power and record 
pertinent information for later processing. 
Development Tools. The servo code also performs func- 
tions that aided in the project as a whole. Features such 
as data capture, error injection, and peak force detection 
were designed into the firmware in its early stages. Data 
capture provided designers with a multichannel "mechan- 
ical oscilloscope" to observe key variables used in the servo 
interrupt (see "Data Capture," page 29). Error injection al- 
lowed designers to simulate error conditions within the 
servo code and observe the system's response (see "Error 
Injection,' 1 page 33). Peak force detection provides servo 
information that was used to identify movements that were 
stressing the design margins of the mechanical assemblies, 
Hooks for the mechanical regression test were used to de- 
termine how well a unit was operating over time, 

Mechanism Code 

The mechanism code provides a translation between the 
SCSI interface and the servo code. Commands are received 
and executed by transforming them into a series of smaller 
submoves. Adaption, error detection, and recovery func- 
tionalities also reside in the mechanism code. 

The mechanism code accepts high-level commands from 
the autochanger interface, executes the command, and re- 
turns status, High-level commands include the following: 

■ Move/Exchange. Move cartridge I'mrn elemen! A to ele- 
ment B* 

■ Seek. Position transport at target element. 

■ Test. Test for the presence of a cartridge at a target ele- 
ment. 

■ Actuate Mailslot, Rotate the mailslot assembly to per- 
form I/O with the user. 

An element is defined to be any possible resting place for 
a cartridge, including storage magazines, optical drives, 
the mailslot, and the transport. 

The commands are transformed into a series of basic 
autochanger operations, such as; 

■ Vertical Move. Position transport to a vertical position, 

■ Translate. Position transport to access a given vertical 
stack of cartridges. 

■ Flip. Relate the transport. 

■ Cartridge I/O. Control the plunger to move cartridges 
between the transport and the magazines, drives, or 
mailslot. 

■ Rotate Mailslot. Control the plunger to rotate the mailslot 
assembly to or from the user. 

For example. "Move element 11 to element 2 with flip" 
would be transformed into the following sequence of auto- 
changer functions: 

1) Determine that element 11 is a storage slot and element 
2 is a drive. 



2) Determine if a translate is required to position the trans- 
port to the appropriate stack for the storage slot. If so, 
perform the translate. 

3) Perform vertical move to the storage element. 

4) Get cartridge from the storage element; 

5) Perform flip, 

6) Determine if a translate is required to position the trans- 
port to the appropriate stack for the drive. If so, perform 
the translate. 

7) Perform vertical move to the drive element. 

8) Put cartridge into the drive element. 

Each autochanger function is then transformed into a 
series of small movements called submoves. There are two 
types of submoves: 

■ Move [Y.Z]. Move motors a given distance at a specified 
acceleration and peak speed. 

■ Saturate [Y r Z). Same as a move except that motion is 
halted if force exceeds a specified threshold. 

Move (Y.Z) is used for high-speed, unobstructed move- 
ments of a known distance. Saturate (Y,Z) is for low-speed, 
adaptive movements of variable distance. 

Autochanger functions consist of one or more combina- 
tions of move (Y,Z) and saturate (Y,Z) submoves. Each 
function has a tailored set of these submoves that guaran- 
tees that the movements will be gentle. As the submoves 
are executed, the servo gains are adjusted to allow for 
changes in load characteristics. An example of the process 
for a flip is outlined below: 

1) Move plunger backwards a fixed distance to engage the 
flip lock. 

2) Change gain for flipping, 

3) Move plunger backwards a fixed distance to perform 
the flip. 

4] Ensure that the flip is completed by performing a satu- 
rate until the force exceeds a fixed threshold, 

5) Change gain for plunger movement. 

6) Move plunger forward to relieve the force. 

Each suhmove within a function has a unique set of 
Stability, performance, mTor recovery, force, and reliability 
crltera, Kach submovs is assigned a unique identification 
code (ID) which is nsed to determine how the move should 
be performed. Before a submove is executed, its ID is used 
to fetch acceleration, velocity , and force limits to use. If 
the move fails, its ID is used to determine the type of error 
recovery scheme to employ, This tailored technique pro- 
vides gentle, stable control of the mechanism, thus increas- 
ing reliability* 

Adaption 

Adaptive algorithms were developed to increase reliabil- 
ity and decrease sensitivities to dimensional variations. 
Dimensions that require adaption are the translate distance, 
flip distance, magazine depths, mailslot depth, and mail- 
slot actuator throw. If a dimension is susceptible to vari- 
ation, the firmware is designed to measure the distance 
using a two-step process. Tin? first step is to undershoot 
the typical position using a move. The second step is to 
perform a saturate until a hard stop is encountered. The 
amount of variation is calculated and the proper dimen- 
sional adjustment is made. Subsequent operations will be 
performed at full speed using the newly calibrated dimen- 
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stoii This form of self-correction eliminates unnecessary 
impulse forces caused by tolerance buildup. 

Adaption is also used to increase the reliability of the 
auto changer/drive interface. Initially, drive insertions are 
performed at slow speeds. An adaptive technique is em- 
ployed to measure the poinl a1 which the drive accepts the 
cartridge. The results are used so that subsequent insertions 
are exact and can occur at high speed. 

Mechanism Initialization 

For the servo firmware to be able to perform controlled 
movements, the mechanism must he methodically set into 
a known initial state. This process of initializing the trans- 
port system is referred to as finding home. The successful 
completion ol the find home routines is crucial for the 
proper operation ol ihe autochanger. 

The transport mechanism is designed to operate through 
a number of degrees of freedom using only two servo 
motors. As a result, motions such as flip, translate, and 
insert/extract require the servo to move the transport thumb 
to specific absolute positions within the transport sleeve 
(see article, page 14). The translate motion, in addition to 
requiring a specific location along the transport sleeve, 
requires an absolute reference point at the bottom of the 
auiochanger^ These positional requirements necessitate the 
accurate and repeatablc location of two points of origin 
from which the servo can reference its motions. These are 
called the plunge origin and the vertical origin. Once these 
points of origin are found, the servo can reliably perform 
all of its fundamental movements. However, the auto- 
changer may have pow T er removed at any time during one 
of its motions. This implies that upon subsequent restora- 
tion of power, the mechanism may not be in a state that 
facilitates locating these points of origin, The find home 
algorithms must therefore be capable of interpreting the 
current state of the mechanics through various feedback 
methods, moving the mechanics in such a way that location 
of the points of origin is possible, and finally locating the 
points of origin in a very repeatable and reliable manner. 

To interpret the current state of the mechanics upon 
power-up, the find home process employs a number of 
algorithms collectively referred to as initial recovery. These 
algorithms are charged with assessing the state of the me- 
chanics using position feedback and force sense of touch. 
Once sufficient information has been gathered, these al- 
gorithms are also responsible for maneuvering the mecha- 
nism to a position from which it is possible to complete 
the find home process. Each initial recovery algorithm is 
designed to perform specific motions assuming a certain 
mechanical configuration and/or range of position. There- 
fore, each algorithm is most effective when used with a 
specific move type. To choose the recovery algorithm that 
best matches the current state of the autoohanger, the non- 
volatile RAM is examined to determine the ID of the last 
movement that was occurring when the power w T as re- 
moved. This number is used to select the appropriate initial 
recovery routine. 

Once the initial recovery routine has completed, the find 
home process can proceed with locating the plunge and 
vertical origins. This process involves a number of steps 
that must be performed in a specific order. The transport 



mu si complete a full flip so that the mechanical hard stop 
along the plunge axis can be located. Force sense of touch 
is employed to locate this point and the servo firmware 
initializes the plunge axis position to zero. The transport 
can then be moved downward to locate the vertical hard 
stop at the bottom of the autochanger. After this is deter- 
mined using force sense of touch, the vertical position is 
initialized to zero. The last basic find home motion is per- 
formed by sensing which vertical stack the transport is 
facing. Once the two axis origins have been located and 
the correct stack has been set, the mechanism is able to 
perform all of its fundamental motions. 

Three more operations are performed that provide the 
firmware with additional information. The first involves a 
slow traversal of the two vertical stacks while monitoring 
the vertical force. This motion ensures that the entire path 
is free of obstructions. The second involves determining 
whether there is a cartridge in the transport sleeve. This 
is performed by moving the plunger slowly outw r ard to- 
wards a solid section of the mailslot while monitoring the 
force exerted. The presence or absence of a large force 
increase denotes the presence or absence of a cartridge. 
The third operation involves determining which side of 
the transport sleeve is facing upward. This piece of infor- 
mation is important since it helps determine the orientation 
of the cartridge before it is inserted into a magnetooptical 
drive. These drives arc single-sided devices, so proper 
orientation of the cartridge is vital to the successful comple- 
tion of a move or exchange command. 

The accurate positioning of the front of the transport is 
critical for reliable insertion and retraction of cartridges 
into and from the magazine slots and magnetooptical 
drives- The servo system is capable of very accurate posi- 
tioning of the transport mechanism. However, vertical mo- 
tion of the transport is controlled from the horizontal car- 
riage assembly, which is In the rear of the transport. 
Mechanical tolerances and variations in the manufacturing 
of the transport assembly may result in the mechanism's 
not being exactly perpendicular with the vertical axis, In 
addition to a deviation from perpendicular, the front of the 
transport may change its vertical position in flipping from 
one side to another and horn changing from one vertical 
stack to another. To compensate for these three variations, 
two optical sensors are employed in conjunction with 
firmware algorithms to calibrate the transport syslem. 

Transport Calibration 

The accurate positioning of the front of the transport is 
critical for reliable insertion and retraction of disks into 
and from the magazine slots and optical drives. The servo 
system is capable of very accurate positioning of the trans- 
port mechanism, How T ever T vertical motion of the transport 
is controlled from the horizontal carriage assembly, which 
is in the rear of the transport. Mechanical tolerances and 
variations hi the manufacturing of the transport assembly 
result in a mechanism that may not be exactly perpendicu- 
lar to the vertical axis. In addition to a deviation from 
perpendicular, the front of the transport can change its 
vertical position in flipping from one side to another and 
in changing from one vertical stack to another. To compen- 
sate for these three variations, two optical sensors are em- 
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Data Capture System 



Early in the development of the autochanger, a was found that 
much of the servcmecrianTcal testing and evaluation col 
be performed by visual observation. The unaided eye was suffi- 
cient !o diagnose gross mechanical problems at slow speeds 
However, the design team needed some way to nsirument the 
au too hanger so thai servo and mechantcal parameters could be 
accurately correlated and analyzed. Typical methods of mea- 
surement would have involved the use of acceterometers a 
high-speed cameras to provide dynamic measurements These 
techniques were dismissed since they could not provide many 
of the measurements needed by the team, and because of the 
difficulty 01 synchronizing their output with simultaneous mea- 
surements of the servo loops, A "mechanical oscilloscope" was 
deemed necessary to facilitate the debugging of high-speed, 
dynamic problems and to ass-st the designers m the evaluation 
of design modifications. Thus, the data capture system was born, 

The data capture system is a combination of firmware-resident 
procedures and workstation -nased tools. It provides the design- 
ers with the means to examine the variation of any important 
firmware variable with respect to time. The capture system em- 
ploys the HP 64000 emulation system in conjunction with "home- 
grown" data processing and plotting tools. It is designed to be 
used in a windowed environment, since its output is displayed 
as an X-Y graph of the variables of interest, Autopiot. a very flexible, 
gen era I -purpose plotting program, displays the output data in a 
graphics window for quick viewing The beauty of the system «s 
that no special hardware is needed, assuming that one has a 
workstation and an emulation system In our case, each firmware 
designer had both of these, so each designer also had a com- 
plete data capture system. This greatly improved the team's 
productivity and ability to debug complex, dynamic servo- 
mechanical problems 

Since the servo system contains accurate position information 
and is operated on a repeatabte time base (one-millisecond in- 
terrupt cycle), It is an excellenl choice for a mechanical measure- 
ment system. Positions, velocities, accelerations, and forces are 
accurately measured in the servo loops and are maintained in 
digital format The data capture firmware exploits this by simply 
copying the values of these variables into a buffer during the 
servo interrupt cycle, In this way, a log of sampled data is created 
that can be processed snto graphical format. 

The data capture system allows a number of variables (up to 
10) to be traced simultaneously during a user-specified length 
ol time. The sampling period can be set from the highest resolu- 
tion of one sample per millisecond down to the lowest of one 
sample per 255 rrulli seconds, in addition, the trigger event that 
begins the data trace can be set to one of lour different conditions: 
(1 ) the first occurrence of a specified move ID, (2) the first occur- 
rence of a specified error code. (3) the occurrence of any error 
condition, or (4) a special event that can be inserted into the 
firmware specifically for debugging. The trigger location within 
the capture time is also user-definable and can be set at the 
beginning, the center, or the end of the capture period Thts 
feature makes it possible to view data that immediately follows 
the trigger event, data thai surrounds the trigger event, or data 
that precedes She trigger even? 

Data Capture Operation 

Fig. 1 shows how the data capture system operates The cap- 
ture parameters for a specific trace (variables of interest, sample 
period, capture time, and trigger condition and position) are 



a text file A shell sc <ed that conve- 

text file into an HP 64000 commanc script After ex~ 

md scnpt m the emulation w>ndow. the data capture sys- 
tem is armed and awaits the trigger condition, At this point, me 
data capture routines begin copying the values of the specified 
variables into the data capture buffer, which is located in an 
unused area of emulator RAM These routines copy the variables 
into sequential memory locations in the bulfer every sample 
period The size of the capture buffer is determined by The number 
of variables the size of each variable (byte, word, or long word), 
e between samples, and the capture duration, The capture 
firmware uses pointer arithmetic to keep track of the begmn rig 
and end of the buffer, and to implement a circular buffer. Once 
the capture system is enabled, the autochanger s instructed to 
perform the motions that will cause the trigger event to occur. 
When the trigger condition occurs, the remainder of the capture 
buffer is filled with data 

At this point, another command script is executed in the emu- 
lation window. This script copies the contents of the buffer mem- 
ory to a file. This data file is then processed by a program called 
mkplt. which generates autoptot commands as its output. The infor- 
mal on displayed in ihe output plot is determined by parameters 
located within the data capture configuration file. These pa ram - 
eters define wh^h captured variables should be plotted on each 
axis, what scaling factor should be applied to each variable, and 
whai titles should be placed on each axis. Mkplt also allows simple 
math functions to be performed on the variables (e.g., plot "van 
- var2" or plot "- var3") Any of the captured variables can be 
used as the independent variable instead of time. For example. 
it is possible to plot the measured vertical force along the Y axis 
and the measured vertical position along the X axis, The mechan- 
ical regression utilities make use of this feature to generate a 
plot of friction versus position along a given mechanical axis 

A new data I race can be created by reexecuting the HP 64000 
command script, exercising the autochanger. saving the buffer 
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Fig, 1. Operation of the data capture system. 
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data, and then plotting the resulting data file. A trace of different 
variables triggered by a different event can be captured easily 
by simply editing a new configuration file and repeating the 
aforementioned process 

Fig. 2 is a pfot generated by the data capture system. The 
data for this plot was captured during a vertical motion of the 
autochanger's transport mechanism. Jt shows the position, veloc- 
ity, and force applied by the vertfcal motor. 

Second System 

A second data capture system was developed thai further 
exploits the hardware on the autochanger controller board. This 
system collects a few vital bytes of data every 10 milliseconds 
and transfers this data to a workstation for collection and postpro- 
cessing. The controller board contains an RS-232 port, which 
can be connected to a terminal for debugging purposes. The 
design team determined that mis interface was capable of trans- 
ferring 18 bytes of data every 10 milliseconds if the baud rate 
were set at 19,200 baud. Using this information, the designers 
decided upon a select number of important variables thai would 
be most useful in deciphering and debugging error conditions. 
Firmware was written thai gathers these bytes of data and trans- 
fers them to the RS-232 port upon demand. 

Data collection is accomplished by first establishing a physical 
connection between the autochanger under test and an HP-UX 
workstation via an RS-232 port. The cu program (eg is a standard 
HP-UX communication program) is invoked on the workstation 
and its output is redirected into a file. When the appropriate 
command is typed, the autochanger firmware begins transferring 



Fig. 2. Typical data capture sys- 
tem plot. 

the 1 8-byte packets of data to the workstation . This data collect bpn 
may last from seconds to hours, depending on the objective of 
the autochanger testing. The output file can be processed con- 
currently with the data collection or examined after the data trans- 
fer is completed. 

Two programs were developed to process the data produced 
by this system The first, called pll. is used to filter out any incom- 
plete packets of data, The first byte of data in each packet is a 
counter, which is incremented after each packet is transferred, 
This is used by ptt to screen out any data dropouts. The second 
program, mcspit. is a postprocessing program similar to Ihe one 
used in the emulation-based capture system However, this pro- 
gram offers many more triggering and display features. With 
mcspit, it is possible to scan through vast amounts of data and 
plot only the specific condition or conditions that are requested, 
Statistical values, such as minimum, maximum, and mean force 
measured over minutes or hours, can be plotted quickly, A 
weekend's worth of data, collected from an operating auto- 
changer. can be easily scanned to locate and examine the events 
that led to a specific error code The usefulness of this tool in 
debugging infrequent error conditions cannot be overestimated. 
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ployed in conjunction with firmware algorithms to cali- 
brate the transport system, 

The autochanger is designed so that all magazine slots 
and drives are accurately mounted and referenced to the 
walls of the autochanger structure. The optical sensors are 
also accurately referenced to this same structure and each 
one's trip point is very tightly specified. Hence, the distance 



from the trip point to any one of the vertical locations is 
known within a very small mechanical tolerance, The 
firmware contains a table of these distances stored in ROM. 
By measuring the height of the sensors with respect to the 
vertical origin, the firmware is able to position the front of 
the transport accurately at any storage slot or drive. Mea- 
surement of I hese sensors is performed by moving the trans- 
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port down toward a sensor (with the plunge leadscrew 
facing upward) while monitoring the output slate of that 
sensor, The state of the sensor will change when the appro- 
priate flag on the transport sleeve interrupts the optical 
beam. When this occurs, the vertical encoder position is 
d as the height of the sensor. A similar measurement 
is performed after the transport sleeve has been flipped 
and the plunge leadscrew is facing downward, The differ- 
ence in height between the two sides of the sleeve is stored 
as another calibration offset. Thus, accurate positioning to 
a given storage slot or drive entails a combination of three 
distances: (1) the mechanical distance from the optical sen- 
sor to the slot or drive of interest, (2) the distance from the 
vertical origin to the optical sensor located in the same 
stack as the slot or drive of interest, and (3) an offset result- 
ing from the orientation of the transport sleeve. 

Service 

li is important that the find home and calibration pro- 
cesses be as adaptive and fault-tolerant as possible* since 
proper operation of the autochanger depends upon their 
successful completion. If these processes cannot be sue- 
cessfully completed, then the autochanger is inoperable 
and must be serviced by a customer engineer. Unnecessary 
sendee calls negatively impact the product's reliability and 
add to its cost of ownership. For these reasons, much effort 
was spent on the design of the find home algorithms in an 
effort to make them as robust as possible. 

In the event that something has broken within the au- 
tochanger. repair time can be significantly reduced if the 
autochanger can make intelligent inferences regarding the 
faulty components. The find home and calibration routines 
perform checks after each motion In determine if an incor- 
in.l (.onditiun exists. If such a condition exists, the firm- 
ware will set an appropriate error code and will suggest a 
list of up to three field replaceable units that it believes 
may be faulty. This self-diagnosis allows the customer en- 
gineer to verify and repair the faulty units rapidly. 

Error Recovery 

Error recovery is the process by which an unexpected 
rendition is rectified so thai nnrr-i.il operation can con- 
tinue. In the autochanger mechanism, errors may occur for 
a number of different reasons, Some of these reasons are: 

■ The host computer requested that a cartridge be moved 
from a location that did not contain a cartridge. 

■ There is a temporary mechanical misalignment because 
of the dynamic nature of the mechanism, 

■ A power failure has occurred during a movement, 

■ There has been a mechanical or electronic failure of the 
autochanger. 

The error recovery firmware is designed to recover from 
a plethora of different error conditions and provide accu- 
rate information to the host computer regarding the status 
of the mechanism. 

The four functions of the error recovery routines are error 
prevention, error detection, restoration of the mechanism 
to normal operating conditions after an error is detected, 
and completion ol the command during which the error 
occurred. Error prevention involves verifying that the re- 
quested source location contains a cartridge and that the 



requested destination location is empty. This is done by 
examining an array in nonvolatile RAM that contains the 
status of each element within the autochanger. If the 
firmware believes that the requested move would result in 
an error, the command is rejected before any motion is 
attempted. This method of prevention, although very reli- 
able, is not foolproof. The element status array may be 
incorrect if a customer engineer manually moves cartridges 
around within the autochanger without reinitializing the 
element status array. In this event, the firmware musi 
on the second facet of error recovery, namely error detec- 
tion. 

Error detectioti is the means by which the firmware de- 
termines that something out of the ordinary has occurred 
within the autochanger. The firmware detects errors in two 
ways. The first involves the servo Loop monitors, which 
run continuously during autochanger motion. These 
routines monitor the forces that are being exerted by the 
vertical and plunge axes. If either of the measured forces 
should exceed levels specified for a given motion, the 
monitor routines immediately disable the servo system and 
set an error flag. 

The second method of detection involves the use of force 
sense of touch at key positions during cartridge move men L 
While a cartridge is being extracted from its storage slot, 
the firmware moves the transport thumb outward slightly 
beyond the point at which it should engage the cartridge. 
If no change in force is encountered during this move, then 
the storage slot is assumed to be empty and an error has 
occurred. Upon returning a cartridge to a storage slot, the 
same outward movement is performed to ensure that a car- 
tridge was in the transport. In addition, after retracting the 
thumb hack into the transport, a small vertical motion is 
performed while monitoring the force on the vertical axis. 
A large change in the vertical force signifies a failure by 
the mechanism to release the cartridge. Similar tests are 
performed when inserting and extracting cartridges into 
and from the optical drives. 

The design of the error recovery firmware is p$0 Scaled 
on the assumption that because of the simple and reliable 
design of the mechanics, error conditions should occur 
very infrequently- This means that the execution speed oi 
the error recovery routines can be reduced significantly 
without negatively impacting the overall performance of 
the autochanger. As a result, the firmware controlling the 
normal operation of the autochanger is greatly simplified 
by partitioning the code so that all error recovery algorithms 
are consolidated into one functional area and all motion 
control firmware resides in another, A simplified hierarchi- 
cal diagram of the motion control firmware and error recov- 
ery firmware is shown in Fig. 4, 

The motion control firmware is designed to complete its 
execution regardless of the slat us of the servo system. The 
lowest- level procedures that perform motion control test 
the status of the servo system. If the servos have been dis- 
abled, the procedures simply return and no motion is per- 
formed. All attempts to modify mechanism state informa- 
tion occur via procedures that verify the status of the servo 
system. These state variables will not be modified if the 
servos have been disabled. Therefore if an error occurs, 
the motion control firmware completes its execution in a 
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Fig, 4. Simplified hierarchtca! dia- 
gram of the motion control and 
error recovery firmware. 



normal manner, but no motion occurs and the state of the 
mechanism is preserved. This provides the error recovery 
firmware with a snapshot of I he mechanism at the instant 
that an error occurred. Error recovery can then proceed 
with restoration oi the mechanics. 

As can he seen in Fi^. 4, ERRQFLRECOVERY is composed 
of the two procedures: FINO_HOME and NEW_COMMAND_ 
GENERATOR. These two procedures can be thought of as 
physical recovery and logical recovery procedures, respec- 
tively. The FIND HOME procedure is responsible For success- 
fully maneuvering the mechanism out of the error condi- 
tion and then restoring the mechanics to a known initial 
state. It makes extensive use of the snapshot of state infor- 
mation that was preserved when the error occurred, and 
of information gathered via force sense of touch move- 
ments, FIND. HOME is the same procedure that is used for 
power-up initialization. Therefore, once it completes, the 
mechanism is in a known state and safe motions can be 
performed, FINDJHOME is invoked by ERROR RECOVERY 
whenever a physical error has occurred that forces the ser- 
vos to be disabled, The logical recovery segment of ERROR. 
RECOVERY is dependenl upon FIND HOME 1 * .successful com- 
pletion. If F1ND.HOME does fail, then ERROR .RECOVERY as- 
sumes that something is drastically wrong and calls a routine 
that attempts to diagnose the failure of the mechanics. 

The NEW_COMMAND_GENERATOR procedure is composed 
of a number of routines that perform three main tasks. The 
first is to examine the original command and the current 
stale of the machine. The second is to generate a new T com- 
mand that will either gather more information, attempt to 
complete the original command, or attempt to restore the 
autochanger to the configuration that existed just before 
the original command was issued. The third task is to send 
the newly formed command back to the PERFORM_MOTIONS 
routine to be executed. This process may be repeated a 



number of times to complete a command or restore the 
autochanger successfully. This looping process is initiated 
by any movement error that occurs while PERFQRM.MQ- 
TIONS is executing. Once in this loop, ERROR_RECOVERY is 
directed by a slate machine which determines how to re- 
solve the error condition or exil gracefully. Kach type of 
motion command (move cartridge, exchange cartridges, test 
for cartridge, seek to cartridge, or rotate mailslot) has a 
state machine sequence that is designed to solve the spe- 
cific recovery requirements of that particular motion type. 
However, all state machines are composed of four common 
states: error recovery initialization, retry the original com- 
mand, restore the autochanger to its original configuration, 
and return a pass or fail status. A detailed state diagram 
for the move cartridge error recovery algorithm is given in 
Fig. 5. 

An error that occurs during a move cartridge command 
will cause ERRGR_RECOVERY to begin execution. The error 
recovery state machine is set to its initial state, during 
which the original move command is stored for later use 
and FINDJHOME is invoked to return the mechanism to a 
known state. FINDJHOME will then return a pass/fail status 
and will provide information regarding the presence or 
absence of a cartridge in the transport. The state machine 
changes to the TesLSource state, during which a test for 
cartridge command is generated. This command is passed 
back to the PERFORM_MOT10NS procedure, which will exe- 
cute a physical test of the source location for the presence 
or absence of a cartridge. The result of this test is passed 
back to ERRQR„RECOVERY. If a motion error occurs during 
this lest, ERROR_RECOVERY will invoke FINDJHOME to re- 
solve the error and the same test for cartridge command is 
repeated. This process can be repeated a number of times, 
and if motion errors continue to occur, the state machine 
will decide that error recovery has failed. However, if no 
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Fig. 5. State diagram tor the move cartridge error recovery 
state machine 

motion error occurs, the state machine proceeds to the 
TesLDest state, during which another test for cartridge com- 
mand is generated and passed back to PEFORM.MOTIONS. 
The destination location is then physically tested and I he 
result is passed back to ERRQFLRECOVERY. As with the 
Test.Sourca state, any motion error will cause FIND-HOME to 
be executed rigain along with a reexecution of the test tor 
{■art ridge command. 

At this point, ihe state machine knows whether the 
source, destination, and transport are full or empty. Any 
full/empty combination that should not logically be possi- 
ble (such as the source being empty, the transport being 
full, and the destination also being full] causes error recov- 
ery to fail and an appropriate error status is returned to 
the host. If the source is empty, the transport is empty, and 
the destination is full, then the command must have com- 
pleted and the state machine proceeds to the Error. Recovery. 
Passed state. Otherwise, the state machine proceeds to the 
Retry state and the appropriate move command is generated. 
This command is either a move from the original source 
to the original destination or a move from the transport to 
the destination. 

The command is once again passed back to PERFORM. 
MOTIONS and a cartridge movement is attempted. If it is 
successful, the state machine proceeds to tire Error. Recovery. 
Passed state. Otherwise, FIND.HOME is again invoked and 



Error Injection 



Error rec . -ery complex procedure, as explained in 

the ac " a article The number of possible situations from 

which the autochangef must recover - 3**ge To 

: ^ i red many eng ioeer- hou rs 
e development team didn't have In addition many errors 
are extremely difficult to induce Since the error recovery testing 
had to be repeated every time the € 

changed, it was deemed necessary to have error injection built 
into the product for the purpose of testing error recovery 

The error injection facility ts enabled via the SCSI so that tests 
can run automatically. It can inject errors for any move at any 
position. Multiple errors can be queued The facility injects errors 
at the lowest possible levef for maximum firmware testing It can 
as so simulate power failure. 

The built-in error injection firmware can be divided into two 
major functions setting up the error trigger and injecting the error 
Setting up the Error Trigger. The objective of error injection is 
to be able to inject ail possible errors for any move at any position 
on the vertical or plunge axis. All motion is broken down into 
many submoves. Each sub-move is assigned a unique move ID, 
When the SCSI command is sent to enable error injection, all the 
pertinent information needed is sent with that command to set 
up the trigger conditions. The injection information includes the 
move ID to trigger on, the axis to trigger on. the posihon to trigger 
on, and the type of error to inject. 

Injecting the Error. Once the error injection command is sent 
over the SCSI, the built-in error injection firmware is then armed 
ana waits for the trigger conditions to be met When the trigger 
conditions are met, the error will be injected Three types ot 
errors can be injected 

■ Servo monitor error The servo monitor status ts intercepted 
and an injected status is substituted. The injected status may 
be overforce, overcurrenl, or overvoitage This simulates unex- 
pected physical errors. 

■ Force sense of touch error. The status returned from the force 
sense of touch is intercepted and an injected status is substi- 
tuted. For example, when the autochanger is expecting to feet 
a cartridge, an error can be injected to tell the autochanger 
that it did no! feel the cartridge 

■ Powerfail error. When the trigger conditions are met, the built-in 
error injection firmware simply jumps to the power -up vectors 
This makes it possible to test powerfail operation automat ica if y 
for all situations. 

Automatic Testing 

Having error injection capability was only the beginning Ihe 
next step was to develop test suites that could could be run from 

an SCSI host to test the autochanger automatically Developing 
these tests was the major part of the overall error injection testing 
development. The test suite not only had to send the appropriate 
injection commands to enabie error injection, hut also had to be 
smart enough to issue the correct SCSI move command to trigger 
the injected error, and to check for the proper SCSI status. The 
following test suites were developed: 

■ Inject errors for all possible move JDs 

■ Inject errors at predetermined risky positions 

■ Inject errors at random positions 

■ All of the above with powerfail errors injected. 

Rick Kato 

Development Engineer 

Greeley Storage Division 
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the stale machine returns to the Test_Locaiions sequence to 
determine: which locations are full or empty. Once theTesL 
Source and Test _Dest functions have completed and returned 
the status of both locations, the state machine cycles back 
to the Retry state and either a Move_Source_to. Oest or a Move 
Trans portJo^Dest operation is initiated, depending on the 
presence or absence of a cartridge in the transport. This 
retry sequence may also be repeated a number of times if 
motion errors con t in tie to occur, and then the stal e niach i ne 
will proceed to the Restore state. 

A very si m Mar chain of events occurs in the Restore stale, 
excepl that iti Ellis slate the exit criterion is ihe successful 
restoration of the autochanger to the configuration thai 
existed before the original command was attempted, The 
move commands that are generated will attempt to place 
ihe cartridge back into the source location, As with fcftfl 
Retry state, any movement errors that occur during an ai- 
ternpted restore will cause the state machine to cycle be- 
tween the TesLLocations sequence and the Restore slate. This 
process may be repeated a number of times, after which 
the state machine arrives at the Error_ Recovery .Failed slate. 
Once the state machine is in either the Error_Recovery Passed 
or the Error_RecQvery_Faiied state, the appropriate status infor- 
mation is returned by MOVE_WITKERROR_RECOVERY \o the 
host and error recovery is complete. 

Firmware Development Environment 

A number of factors conlrihuted to the successful de- 
velopment of the autochanger firmware. One significant 
factor was the use ol individual workstations connected 
by a local area network (LAN). This networking provided 
independent access to a common set of source code. The 
code files for the project resided on one hard disc P and 
each development workstation used the Network File Sys- 
tem (NFS)' to gain access to Ihe files. Each workstation 
had ihe same view of the source code, but each firmware 
designer was able to work independently on an HP 9000 
Model 370 workstation. The bottleneck normally produced 
by editing, compiling, and linking on one machine was 
removed. In addition to increasing the designers' produc- 
tivity, the use of a common set of code files facililated 
revision control, tool development, and system administra- 
tion. 

Another factor that greatly contributed to the au- 
tochanger program was the development of the data capture 
tool (see box, page 29]. This tool provided a means for 
capturing and displaying any time-varying global variable 
within the firmware. Data capture was primarily used to 
focus on mechanical or servo aspects of the autochanger, 

NetwoTlt File System ~m a t>rcjduc1 at Sun Mcosysir-mr; 



an h m the position, velocity, or force of one or both axes 
of motion. It provided the designers with a 4l mechanical 
oscilloscope 1 ' that produced enlightening views inlo the 
Operations of the autochanger. Hence, il was extremely 
useful in examining and diagnosing operational errors. 

While dala capture provided useful insight regarding er- 
rors thai occurred during the autochanger development, 
another loo I provided the means for exercising the error 
recovery code without requiring lhal specific errors occur. 
The error injection tool (see box, page TX] allowed the 
firmware designers to force an error to occur during a spe- 
cific motion and at a specific position or range of positions. 
By using this tool, the many different states of the error 
recovery code could be debugged, tested, and verified. 
Since an error can occur during any portion of the mecha- 
nism's operation, simulating all errors by physically induc- 
ing an error would be extremely difficult to do. Error injec- 
lion solved this problem and provided a powerful and flex- 
ible means for ensuring the reliability of the error recovery 
firmware. 

A I bird to©] that contributed to the firmware develop- 
ment was the mechanical regression test suite. This sel of 
procedures provided the means to measure various 
mechanical aspects of each unit. Friction tests, spring con- 
stants, hard stops and datum, performance measurements, 
and servo parameters could be acquired using these 
utilities. Measurements could be taken, then lesls run and 
ihe measurement rerun to assess various factors (degrada- 
tion over time or lernperalure, effectiveness of a part or 
design change, haseline measurement). These routines are 
now used during the manufacturing process to assess the 
correctness of the unit's assembly. 
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Qualification of an Optical Disk Drive 
for Autochanger Use 

Ninety-three design changes were made to the stand-alone 
drive to qualify it for use in an autochanger 

by Kevin S, Sa Ida nfo a and Colette T\ Howe 



IN ADDITION TO THE USUAL requirements of data In- 
tegrity, performance, and reliability lor a mass storage 
device, an optical disc drive that is to be used in an 
autochanger requires a well- defined com union at inns and 
mechanical interface that operates efficiently and reliably 
over hundreds of thousands of load and unload cycles. 

In designing the HP Series 6300 Model 20GB.. A rewrita- 
ble optical disk library system , we had control over the 
autochanger end of this interface, buL we hid to work 
closely with the drive vendor to establish the other end. 
The vendor's original design goals had not included use 
of the drive in autochanger environments. Endowing the 
drive with this additional functionality and verifying it 
proved quite a challenge. Between the release of the stand- 
alone product (Model 650/A) and the autochanger product 
(Model 20GB/ A) there were 93 changes to the drive. 

Communications Interface 

We needed a reliable interface to the drive [hat did not 
impair performance by tying lip the SCSI bus. During loads. 
the autochanger needs feedback from the drive to know 
when the drive has accepted .i i artridge that has been in- 
serted. The autochanger also needs to be able to initiate 
ejection of a cartridge from the drive, and during operation 
and under fault conditions, the drive status needs to be 
communicated to the autochanger controller. 

This interface is implemented with two hardwired signal 
lines: an eject line and a busy line. The semaphore on the 
busy line indicates drive status, fault conditions on load, 
and the eh ceptance of the cartridge in the drive. The tinting 
of the signals was worked out based on a thorough under- 
standing of the load and unload sequences and retry al- 
gorithms in the drive. As a result of this effort, we were 
able to provide inputs to the drive vendor that made these 
processes shorter and more reliable. 

The spin-up sequence during loads includes a read of 
prestamped control tracks. Part of this is phase-encoded 
information [PEP) that is read before tracking is established, 
and can take up to 1,5 seconds to read. The autochanger 
requires this information just once, when the cartridge is 
first introduced into it. To eliminate subsequent PEP reads 1 
a third hardwired signal line is included. 

Mechanical Interface 

Except for not using the eject button on the drive, the 
mechanical interface definition is no different from that in 
a manually operated drive. This tS largely because of the 
flexibility of the autochanger architecture. Once we ob- 



tained specifications on acceptable insertion windows. 
angles, and distances, it was possible to program the au- 
tochanger to operate within these limits. The main require- 
ment the autochanger has of the drive is that the cartridge 
eject to a certain minimum distance and with a specified 
minimum force. 

Design Goals 

the metric chosen to gauge the reliability of the drive 
in load/unload cycling was the mean number of swaps 
between failures (MSBF). The drive as released for use in 
stand-alone operation had an MSBF of 5,000, which is 
adequate for manual use. However, this fell far short of the 
target of 40,000 set for the release of the drive for the au- 
tochanger product, With the numerous changes im- 
plemented in the drive and media, we were able to prove 
an MSBF of i nn.ono with a confidence level of 93% at the 
release of the autochanger product. For these products, the 
drive was operating in the normal horizontal mode. Work 
is currently underway on a project that will also allow 
operation of the autochanger and the drive in it on their 
sides in vertical mode. We have already achieved an MSBF 
of 200.000 in both these axes [Fig. 1). 

Test Strategy 

The ideal test vehicle was, of course, Bie autochanger 
n M We could test the drive, the autochanger and the 
interface la conditions similar to acfyia] use. Indeed, this 
is how the bulk of our testing was conducted, and much 
valuable information was teamed from it. As we began 
finding and fixing the more obvious problems, it took 
longer to find the more intermittent and wear dependent 
ones It takes about two months to perform 200,000 swaps 
in an autochanger doing nothing pIso. 

We developed special test fixtures to perform specific 
at much higher rates so we could accelerate the test 
cycle. One of these, the "scrubber," could insert and with- 
draw a cartridge in a loader tray and complete 200,000 
cycles in a week. We also developed a drive tester that 
essentially was a stationary autochanger picker t which we 
used to test drives and cartridges. We also provided one 
of these to the drive vendor so they could duplicate and 
better understand problems that were encountered- 

We maintained detailed records of failures encountered 
by Ihe autochanger. drive, and cartridge. It proved useful 
to keep tlie swap counl of a cartridge on the disk itself. A 
list of all known problems and their resolution status was 
also maintained and updated regularly- It served as a useful 
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Fig, 1. Reliability improvement in 
the optical disk drive. MSBF stands 
for mean swaps between failures. 



measure of how the qualification effort was progressing 
(Fig. 2] 

Problems and Solutions 

We were able to identify and solve problems in several 
areas as a result of this testing, 

The early force-distance profiles used by the autochanger 
during inserts resulted in excessive loads at first contact 
with the cartridge slot door and misdetection of the hard 
stop in the I odder tray. This force profile was tuned to 
deliver a much lower force to the cartridge and to accom- 



modate significant variations in the location of the hard 
stop [see article, page 14). 

We encountered bus hangups stemming from noise on 
the SCSI and the autochanger-to-drive interface lines* Ca- 
bles were .shortened and rerouted away from noise sources 
to eliminate Ihese problems, 

Some of the misload failures observed were attributable 
to misdetection of signals at the communications interface 
between the drive and the autochanger. Changes in timing 
and debouncing of signals both in the autochanger and in 
the drive made this detection far more reliable and fixed 
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Fig. 2, A count of known prob- 
lems was a useful measure of the 
progress of the drive qualification 

effort. 
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these problems. 

Mechanical Problems 

Several mechanical problems were encountered and 
fixed in the course of this development effort. Many of these 
were related to friction wear between contacting surfaces. 

The cartridge, then made of ABS, was subject to heavy 
wear where it made contact with the autochanger picker, 
its shutter, the slot door, the loader tray, and the alignment 
pins in the drives. The ABS dust generated posed a poten- 
tial threat to data integrity if it landed on the disc or the 
objective lens. More immediately, these dust deposits 
caused the cartridge to bind in the loader tray or catch on 
the alignment pins. Measures taken to minimize this in- 
elude coating the loader tray with Teflon, blunting *harp 
lead-in angles uii the tray T increasing the radii of the locator 
pin tips and changing the slot door material to poly carbo- 
nate, 

Dust from wear was also generated within I he cartridge 
from contact with the disk. Thin dust was deposited directly 
on the disk during unloads, when the media spins down 
nolo landing pads on the cartridge. This contamination, 
which started out as a ring at the inner diameter, could 
mi mate out over the control tracks and the data areas, and 
could even find its way onto I lie objective lens, With as 
few as 8.000 loads mlo a drive, an ABS cartridge could 
cause problems such as failure to spin up successfully be- 
cause of obscured control tracks, improper focusing, and 
increases in raw byte error rates. These wear problems were 
overcome by changing the cartridge material to % polycar- 
bonate and by gluing a slip ring onto tiie disk where it 
comes intncnntai 1 wilh Ibe landing pad on the cartridge. 

There was also wear between the drive spindle motor 
shaft and the the disk hub. Wear on the hub resulted in a 
sharp edge, which at some point seized the spindle during 
loads and unloads. These problems were solved by modify- 
ing the spindle and hub geometry to make the capture 
easier and by increasing the spindle hardness. A disk \\ 
ing pad was designed to keep the disk from being loaded 
and unloaded a I an angle. The magnetic chuck that holds 
the disk was modified to provide a stronger capture force- 
distance profile. Further improvements along these lines 
were made for operation of the drive on ils side. The 
strength of a retention spring was increased to compensate 
for the loss of the assistance of gravity in the secure seating 
of the cartridge against the media sensors. 

In addition to mechanical wear problems, we encoun- 
tered a challenging electrostatic discharge problem. The 
cartridges were budding up a charge as they were being 
inserted in drives and magazines and moved around by 
the picker, The cartridges would discharge to the drive 
loader tray. While most of the charge dissipaled I h rough 
chassis GND t il sometimes managed to cause glitches In die 
drive electronics. Reproducing these problems and testing 
fixes was greatly helped by the media testers in use here 
and at the vendor's site. Although alternative conducting 
materials were investigated for the cartridge, the solution 
U> these ESD problems was found in establishing a better 
ground path and putting low-pass filters on susceptible 
drive controller signals 

In the course of improving the load/unload reliability of 



the drive mechanism, the testing conducted was also ben- 
eficial in Increasing the margin for the basic read write 
functionality of the drive. The drive accesses control tracks 
and reads them only during spin-up. These control tracks 
contain preformatted data. It is harder for the drive to main- 
tarn tracking and t i introl tracks than on datatr 
Intermittent tracking problems were observed when a* 
ing these tracks during loads in autochangers. The changes 
that have been implemented to fix this have resulted in 
overall improvements in tracking performance in the drive. 

Open Communication 

Effective exchange of information has been a key ingre- 
dient in the success of this effort, The qualification of the 
drive mechanism and controller for use in manually oper- 
ated stand-alone operation began at HP's Disk Memory Di- 
vision in Boise, Idaho. After evaluating several vendors, 
one was chosen to supply us with both drives and media. 
A second media source was also identified. We began work- 
ing with them to define and qualify the drive and media. 
This effort drew on the expertise of the program in Boise. 

The project was then transferred to HPs Greeley Storage 
Division in Colorado, where work had already begun on 
integrating the drive into a stand-alone product as well as 
into an autochanger. The flow of information between us 
and our vendors had by now swelled to a torrent with 
facsimile messages flying back and forth daily. Despite the 
fact that the drive vendor was in Japan, we were able to 
evolve a very effective working relationship. Aside from 
regular management contacts, we had periodic technical 
meetings both here arid in Japan. These served to establish 
cngineer-to-engineer contacts, It then became easy to direct 
communications lo the right people and obtain quick res- 
olution of issues. We were fortunate enough to be working 
with a responsive vendor and H was nol uncommon to send 
i Facsimile request for information one evening and return 
the next morning to find a response to it. 
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A CD-ROM Drive for HP 3000 and HP 9000 
Computer Systems 

The HP Series 6100 Model 600/ A HP-IB CD-ROM drive 
provides facilities that allow HP 3000 and HP 9000 computer 
system users to access data stored on CD-ROM disks, 
which can store up to 553 Mbytes of audio and digital 
Information. 

by Edward W. Sponheimer and John C. Santon 



THE CD-ROM [com pat.:! disk read-only memory) is 
inidio CD technology used to store computer data. 
The important features of I he CD-ROM are its capac- 
ity* permanence, fast production process, and low per-unit 
production cost. CD-ROMs are ideal for data that is not 
expected to change soon, or information that needs to be 
distributed to a large number of users. 
The ideal applications for the CD-ROM include: 

■ Providing software manuals for computer systems 

■ Providing a large reference document, such as a dictio- 
nary or an encyclopedia 

■ Providing a training package including reading materi- 
als, graphics, arid tests 

■ Providing large-scale software distribution. 

The HP Series 6100 Model 600/A HP-IB CD-ROM drive 
can support software distribution, on-line data or docu- 
mentation retrieval, computer-based training, and other 
multimedia applications. Special software security features 
are designed into the Model 600/A to provide data protec- 
tion and software distribution security, The capacity of 
CD-ROMs allows a whole operating system and other soft- 




Land 



ware subsystems to be stored on one disk. Since customers 
may not purchase ali the subsystem software, the software 
protection scheme ensures that customers have access only 
to the subsystems they purchased. The article on page 49 
describes the software protection scheme employed by the 
Model 600/A. 

The Modei 600/A uses HP Command Set 80 (CS-8QJ pro- 
tocol 1 to communicate with the host computer over the 
HP-IB interface. Command Set 80 defines a set of com- 
mands that enable communication between an HP disk and 
the host computer. For HP 9000 users, the CD-ROM reader 
can be used to read non-HP CD-ROMs provided they are 
created in the ISO 9660 High Sierra standard file format. 
The article on page 54 describes the ISO 9660 support. 

The rest of this article presents an overview of CD-ROM 
technology and the Model 600/A controller board. 

CD-ROM Technology 

CD-ROM is an optical storage technology. Data is read 
from the disk using a laser beam. The CD-ROM is a platter 
120 mm in diameter that has pits [holes] and lands (material 
between holes] on one surface, arranged in a continuous 
spiral (see Fig. 1). The pits and lands represent the informa- 
tion (ones and zeros) stored on the disc. A one is rep- 
resented by a transition from a pit to a land or from a land 
to a pit. and the length of the land or pit represents the 
number of zeros (see Pig. 2) + The pits and lands form a 
track that is 0.6 micrometers wide (track pitch = 1,6 pi) 
which yields a track density of 15.875 tracks per inch. A 
combination of a pit and a land that follows it can run from 
0,9 to 3.3 /im in length, To put these numbers in perspec- 



0001001 0001000010001 



Bit Daift 



Spiral Track 

Fig, 1 , A portion of a CD-ROM surface (not to scale). 



^^^^m Pits and Lands 

Fig, 2. Transition between one and zero and zero and one 

on a CD-ROM. Ones are represented by transitions from p#S 
to tends or from lands to pits. 
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live, the total length of the groove on a CD-ROM disk is 
approximately three miles and the total number of pits is 
almost two billion. A CD-ROM disk can store up to 600 
megabytes of computer data. 

Data is not written on the CD-ROM by the users comput- 
er* Data must be mastered using a specialized publishing 
hss. Subsequent disks can be inexpensively made from 
the master. There axe three steps to making a CD-ROM: 
data conversion, pre mastering, and mastering. In the data 
conversion phase, the data is organized and formatted. Pre- 
mastering adds the error codes and indexes needed for 
efficient CD-ROM use. The master, used to stamp the pits 
in the production discs, is finally created in the mastering 
phase. A new master must be made every time a new disk 
is published, However, once the initial cost of publishing 
the master is done, the cost of reproducing copies is very 
li >v\ 

Recording Format 

The format of how data is formatted on a compact disc 
is specified in two standards called the red hook and the 
yellow book, 2 ' 3 The red book was the first standard and it 
specifies the format for digital audio data The yellow book 
is an extension to the red book and it specifies the format 
for other forms of digital data, particularly computer data. 

Data is recorded on the disk using a code called KFM 
(eighMo-fourteen modulation). The recording circuits use 
a lookup table to convert each eight bits of data to 14 chan- 
nel bits. Three merge bits are inserted after each 14-bit 
symbol to ensure that the symbol ends do not violate the 
rules of the EFIvf code and to equalize the total lengths of 
pits and lands on the disk {see Fig, 3). The smallest size 
of an information unit on the CD-ROM is called a frame. 
The contents of a frame are shown in Fig. 4. The frame is 
the synchronization element for CD audio and the object 
of error correction encoding for computer data, 

The synchronization pattern of channel bits identifies 
the beginning of each frame and does not participate in 



the EFM coding. The control subcode provides some infor- 
mation about the data in a frame such as the presence of 
CD audio or data symbols. The data symbols represent the 
information content of the frame. These symbols can rep- 
resent audio, user data, or a third level of error correction 
coding. The last eight bytes are parity bytes used for error 
correction. 

The 24 bytes of information represented by 588 channel 
hits are combined with other frames of 24 bytes of informa- 
tion into sectors of 98 frames. Sectors occur 75 times per 
second making the transfer rate from the disk 176.400 bytes/s 
(98 frames/sector * 24 bytes/frame X 75 sectors/second). 
The organization of the bytes in a disk sector is shown in 
Fig. 5. 

Error Correction Code 

The mode byte shown in Fig. 5 describes the nature of 
the data contained in the data field of the CD-ROM. The 
yellow book standard defines two modes for computer data. 
In mode 1, the CD-ROM can store up to 553 Mbytes of 
information on a 60-minute disk. Mode 1 uses the 288 
KDOECC (error detection coding and error correction cod- 
ing) bytes to improve the data error rate. In mode 2 the 
CD-ROM can store up to 630 Mbytes because all the bytes 
are used for data (including the 288 EDC/ECC bytes). Mode 
2 can be used for applications in which error rates are not 
critical such as the storage of graphical information, 

For the Model 600/A there are three levels of error correc- 
tion. The first two levels, CIRC1 and CIRC2 [CIRC stands 
for cross interleaved Reed-Solomon t:ode) T are provided by 
the CD audio standard. The third level of error correction 
encoding is provided for mode 1 data by a Reed-Solomon 
product-like code, using the HDC/ECC bytes. The error cor- 
rection data is placed on the disk when it is mastered. The 
first two levels of error correction are done on all data 
fields and are decoded in real time by the CD-ROM drive. 
The third level Is decoded by the CD-ROM controller. See 
the article on page 42 for more information about error 
correction on the Model 600/A. 



B-Bit Data 1 1 1 00010 101 11010 



14-Bit 
Modulated Data 1 001 0001 00001 ,0001 00001 001 00 1 



Added 
Merging Bits 000 10010001000010 001 0001 00001 001 00 i 100 



Channel Bits 



Disk Addressing 

On a CD-ROM disk, the groove is divided into a lead-in 
portion that contains a table of contents, a program area 
that contains user data, and a lead-out area that contains 
all zeros. The table of contents resides in CD-ROM area 
0:0:0 to 0:1:74 (0 minutes, 1 second. 74th frame). The table 





Number of 
Channel Bits 


Derivation 


Synchronization 
Pattern 


27 Bits 


(24 Bits + 3 Merge Bits) 


Control Subcode 


17 Bits 


(1 Byte x 17 Bits Byte") 


Data Symbols 


408 Bits 


(24 Bytes x 17 Bits.' Byte*) 


Error 

Correction 


136 Bits 

588 Bits Total 


(8 Bytes x 17 Bits, Byte") 



Fig. 3. Eight -to- fourteen bit encoding example. 



• 17 Bits-Byte = (14 Modulation Bits + 3 Merge BitsJ'Byte 
Fig. 4. Channel bit format tn a CD f&&n&. 
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Bytes 




Fig. 5, A sector on a CD-ROM disk. 

of contents Contains the absolute address for each existing 
track (from () to 99 minutes). Each track can contain only 
one mode of data storage. Audio tracks and digital tracks 
have buffer areas between them. The start of the user area 
Starts a1 frame location 0:2.13 (logical address 0:0:0). If pres- 
ent, the system area directory resides in the program area 
starting a1 location 0:2:6. The system area data files, which 
can exist anywhere on the disk, contain information used 
by the drive or host computer, such as disk security infor- 
mation, logical sector size, CS-8U volume boundaries, and 
the CD-ROM revision number. The Model 600/A looks for 
a constant in the system area to determine whether a disc 
is an IIP CD-ROM . 

The Controller Board 

The Model 600/A controller board provides the interface 
between the native CD-ROM drive and the host computer- 
It has three sections: the controller, the disk interface, and 
the audio section (see Fig. ti). The controller provides the 
intelligence on the board and is responsible for: 

■ Communicating with the host computer via the HP-IB 
interface 

■ Controlling the CD-ROM drive through the 19.2-kbit/s 
UART 

■ Accessing (he software protection information in the 
EEPROM 

■ Providing the software protection keys to the unserani- 
bier 



■ Programming the 4- Mbytes DMA controller for DMA 

transfers to the host via I lie HP -IB. 

The unscramble! circuit is responsible for decoding the 
data on the disk that is scrambled (encoded) for software 
security. It operates at fj transfer rate of 154 kbytes/s and 
is capable of unscrambling data from the media or from 
the host. If the CD-ROM in the drive is not an HP disk, the 
controller switches the unscrambler out of the inbound 
pa tli of CI J- ROM data. The controller uses the keyword 
information in the EEPROM and the password information 
from the host to del ermine the key for the unscrambler, 

The disk interface provides the entry point for CD-ROM 
data. Data arrives from the disk in bursts of 16 bits at 2.1 
Mbits/s. These bursts occur once every 11 3ti microseconds 
giving an overall transfer rate of 176.4 kbytes/s. The CD- 
ROM data is in serial formal so it must be deserialized 
before being sent to the unscrambler or directly to the HP- IB 
interface, 

The Model f>UQ/A can also play audio information re- 
corded on a CD or a CD-ROM. The CD-ROM standard' 
divides all data ioto groups of 100 tracks and each track 
can be either audio or digital, Audio information from the 
drive is serial and arrives at a data rate of 44,100 16-bit 
sauiples/s on each channel. The samples alternate between 
left and right channels, Audio data reconstruction is ac- 
complished with a 4 x oversampling digital filter with error 
interpolation, and a digital-to-analog converter (DAC) that 
operates at 176 t 400 stereo lb-bit samples/s. The oversam- 
pling filter interpolates between samples and outputs data 
at the rate of the DAC. The filter is used to deal with aliasing. 
When a sampled signal is reconstructed, a Fourier trans- 
form of the resultant signal show r s a baseband signal and 
a modulated carrier at the sampling frequency. If the audio 
rate at 44,100 16-bit samples/s signal is reconstructed and 
the sampled signal is frequency limited to 20 kHz (top end 
of the audio band), the quiet zone, which is the range be- 
tween the recreated baseband signal and its alias, is only 
4.1 kHz wide. To filter out the alias effectively requires a 
very steep low-pass filter (most implementations use a 
seven-pole Chebychev filter]. It's not practical to build such 
a filter without creating some phase distortion in the high- 
frequency end of the the baseband signah By digitally re- 
creating samples between each recorded sample (oversam- 
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Fig . 6. The Model 600/A CD-ROM 
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pling) the signal can be reconstructed at a higher sampling 
frequency, thus increasing the width of the quiet zone and 
decreasing the demand on the low-pass filter. Following 
the DAC is a low-pass filter that attenuates most of the 
alias signal. Finally, the signal is routed to the bacrkplane 
preamplifier and to the potentiometer for the volume con- 
trol which drives an all-pass amplifier that drives the head- 
phones* 

Conclusion 

Compact disk technology started as a technological ad- 
vancement in noise reduction for the musical recording 
distribution industry- It has become a valuable tool in the 
computer industry for the distribution of information, man- 
uals, and software. The HP Series 6100 Model BOO/A HP- IB 
CD-ROM drives which has complete industry -standard 
compatibility, full error correction support, software se- 
curity, and CD audio support, provides the full spectrum 
of CD-ROM technology to HP's computer systems. 
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Error Correction Implementation and 
Performance in a CD-ROM Drive 

The HP Series 6100 Model 600/ A implements the error 
protection algorithm defined by the CD-ROM yellow book 
standard. This extra level of protection means that the error 
rate is improved from one error in 10 12 bits to one in 1Q 1G . 

by John C. Meyer 



IN AN IDEAL DIGITAL transmission channel the infor- 
mation that is input at the transmitter should be faith- 
ful I y reproduced at the receiver. Unfortunately, because 
uf things like noise, power-line fluctuations, and imperfec- 
tions in the media, data can be corrupter! before it reaches 
the receiver. This is why error detection coding and error 
correction coding (EDC/ECC) techniques are incorporated 
in the digital transmission system. The data on the media 
is encoded at I lie transmitting end with the EDC/ECC bits 
and decoded at the receiving end to correct for errors and 
to recover the original data. If there are errors, the EDC/ECC 
algorithms arc designed to detect and correct a certain 
number of errors or to cause retransmission of the data. 
The box on page 46 is a primer on EDC/ECC techniques. 
Because the CD-ROM disk has a very high bit density, 
it has an inherent error rate of 10 5 to 10 fi errors per bit. 
The red book standard, 1 which has become International 
Electrotechnical Commission (IKCj standard 908. specifies 
the CD audio media formal and provides a parity and error 
correction scheme that reduces the error rate to 10~ n to 
tO ■ errors per bit. All CD manufacturers provide this 
level of error protection. 2 3 The yellow book standard, 4 
which is currently undergoing standardization as European 
Computer Manufacturers Association standard 130 H or 
ECMA-130, specifies the CD-ROM format, This standard 
expands on the CD audio standard to include track defini- 
tions for digital data, mixed media disks, and digital data 
representation within a frame. For example, the minimum 
addressable section of a disk is defined by the red book as 
1/75 of a second of audio data or 1 1 7h 16-bit audio samples, 
and by the yellow book it is defined as 2352 bytes of digital 
data or a disk sector. The CD-ROM yellow book specifica- 
tion provides an additional level of error protection that 
reduces the error rate to 1G~ 1:> to ltj~ lb errors per bit. Fig. 
1 summ arises the results of error correction provided by 
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the red book and veltovv book standards. 

The yellow book further defines three modes for sectors 
within data tracks. These modes all have a 16-byte header 
composed of 12 bytes of synchronization data (00, FF,,.., 
FF P 00). three bytes of address data (minute, second, frame), 
and a mode byte (UCJ, 01, or 02 j. Mode t) sector headers are 
followed by 2336 bytes of zeros. These sectors are used for 
lead-in at the beginning of disks, lead-out at the end of 
disks, and transition regions between audio and digital 
data tracks. The table of contents for a disk is contained 
in a portion of the lead-in area. Mode 1 sector headers are 
followed by 2048 bytes of user data and 288 bytes of EDC/ 
ECC data. The KDC/ECC bytes add the extra data protection 
over that which is available at the native interface as 
specified by the red book standard. Mode 2 sector headers 
are followed by 2356 bytes of user data. These sectors can 
be used for bit maps or other data that may not require the 
data protection provided by mode 1. Fig. 2 shows these 
mode formats, 

Red Book Error Protection 

The CD audio standard (red book] specifies two levels 
of parity and error correction which are implemented 
within the drive, The algorithm used for encoding the par- 
ity bytes is called a cross interleaved Reed-Solomon code 
(CIRC). As shown in Fig. 3, there are two CIRC encoders. 
CIRC1 and CIRC2, which provide the two levels of error 
protection. Sectors are divided into 98 24-byte Fl-frames, 
which are processed through the CIRC encoder, which con- 
sists of three delay sections and two encode sections, The 
first delay section interleaves the Fl -frames into two 12- 
byte groups. One group is delayed for two Fl -frame times 
(24 byte times). The interleaved Fl-frames then pass 
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(12 Bytes) (4 Bytes) (2336 Byte a) 



Synchronization Header User Data 

(12 Bytes) (4 Bytes) (2045 Bytes) 



Synchronization Header User Data 
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Fig. 1 . Results of error protection schemes provided by the 
red book and yellow book CD-ROM standards. 



Fig, 2. CD-ROM sector mode formats. 
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through the CIRC2 encoder section, which generates four 
Q-parity bytes using a (28,24)* Reed-Solomon code. The 
second delay section delays the CIRC2 bytes from ON to 
Fl -frame times (N = 4). Time-delayed packets of 28 
bytes then pass through the CIRCl encoder, which gener- 
ates four P- parity bytes using a (32. 28) Reed-Solomon code. 
Finally, the third delay section delays every other byte 
from the CIRCl encoder one Fl -frame time. At [he output 
of the CIRC encoder, the 32-byte packets are called F2- 
frames. 

9 result of all this delaying and interleaving 1 be orig- 
inal F1 -frame bytes are delayed from three to 108 Fl -£* 
times, and they wind up being redistributed over 106 F2- 
frames. Thus, one frame's data is spread over three physical 
set tors on the medi;i, thereby reducing the impact of burst 
errors. An additional control byte is added to the F2-frames 
to form 3 3- byte F3-framos. 

F3-frame bytes are tt-to-14-hit (EFM) encoded and linked 
together with a 24-bit synchronisation header. Three merg- 
ing bits are used between bytes to maintain run length 
limits between transitions on the media. The result is that 
each 192-bit Fl -frame is represented by a total of T>88 chan- 
nel bits on the media [see page 39 for an explanation of 
8.t .14.bU encoding). Most of this redundancy can be used 
for error recovery, either for detection of errors and creation 
of erasure flags or for correction of errors using the P-parity 
and Q-parity bytes, An erasure flag is error location infor- 
mation that is obtained outside the decoding process, usu- 
ally from hardware. If erasure flags are available, the 
number of errors that can be corrected increases because 
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syndrome bytes do not have to be used to locate erro: 
syndrome byte is the result of some parity check on a re- 
ceived code word. Codes are generated so that syn dromes 
are zero when there is no error and nonzero when they 
contain information to locate and correct errors in a code 
word. 

data is read from the disk, the first level of error 
detection is during 14-to-tt-bil decoding i de- 

properly, erasure flags can be set to aid the correction 
process at the CIRCl decoder (see Fig, 4}. The CIRCl de- 
coder uses a (32.28) Reed-Solomon code that has four re- 
dundant bytes and can therefore detect and correct two 
errors, or correct up to four errors if erasure flags are avail- 
able from earlier processes. The CFRC2 decoder uses a [28, 
24] Reed-Sotomon code that can also correct up to four 
errors with erasure flags. Correction algorithms within 
drives do not always take full advantage of the codes* cor- 
rection capability. All manufacturers' implementations do. 
however, use enough of this capability to lower error rates 
from the 10 5 to 10 "'* level nt the disk to the 10 ri to 10 1Z 
level at the interface. 



CD-ROM Error Protection 

The CD audio specification is good for reproducing dig- 
ital high-fidelity sound, since interpolation can be used to 
reconstruct byte errors that are uncorrectable by CIRC en- 
coding. This approach is not acceptable for digital data, so 
the mode 1 CD-ROM specification was created to address 
this deficiency by improving the bit error rales to the 10 " 1 
to 10 "' range, The CD-ROM encoding process involves 
the calculation of EDCand parity bytes for each 204H-byte 
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Fig, 3. CD audio standard CtRC (cross interleaved Reed-Solomon) encoder 
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Fig. 4. CIRC error correction and 
decoding process. 



sector. 

Fig. 5 shows the organization of the 2HH KDC/ECC bytes 
in a mode 1 sector. The EDC portion consists of four cyclic 
redundancy check (CRQ bytes and eighl bytes of zeros. 
The CRC is a simple checksum that is calculated over I he 
16-byte header [12 bytes of synchronization plus the four 
header bytes] and the 2048 bytes of user data. Tbe CRC 
calculates the value of a polynomial and stores the result 
in Ihe four-byte CRC field. P- parity and Q-parity bytes, 
which are not the same as the CIRC parity bytes described 
above, are calculated using the Reed-Solomon product-like 
code. 4 In this algorithm error correction is applied to the 
four header address and mode bytes, the 204H bytes of oser 
data, the four EDC check bytes, and the eight pad bytes. 
This totals 2064 bytes, No error correction is applied to 
the 12 synchronization bytes. The 2064 bytes are arranged 
in two 1032 -byte matrices, one matrix for even- numbered 
bytes and the other for odd-numbered bytes. Kor the <:Mt il- 
lation of P- parity bytes, the matrices are arranged in 24 
rows and 43 columns in row- major order. The P- parity 
bytes are calculated down the columns using a (20,24) 
Reed-Solomon code and appended to the bottom of the 
columns, creating two 26-row-hy-43-{:olomn matrices. Q- 
parity bytes are calculated along the diagonals of these 
matrices using a (45 , 43) Reed-Solomon code and are ap- 
pended to die ends of the rows. This calculation produces 
two 26-row-by-45-columo matrices (2340 bytes). Pi^. 6 
shows these steps. Adding the 12 synchronization bytes 
results in 2352 bytes, which is one CD-ROM sector These 
codes contain enough information to detect and correct 
one error per row and column, or to correct up to two errors 
per row and column if erasure flags are available. Since 
most drive manufacturers provide erasure flags from their 
CIRC implementations, error rates of 10" 15 to 10 16 errors 
per bit can be achieved. 

When the CD-ROM is mastered the Reed-Solomon prod- 
uct-like code is applied to the information bits before the 
CIRCl and CIRC2 encoding. During decoding, the situation 
is reversed with the mode 1 decoding applied last. 
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288 Bytes 
EDC/ECC 



CRC Zeros P-Parity 
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The Model 600. A Implementation 

In the Model 600/A CD-ROM drive, the mode 1 error 
correction algorithm is implemented in the controller. Ex- 
cept for some HP 3000 computer system requirements, im- 
plementing mode l error management was straightforward* 
The most important HP 3000 system requirement that im- 
pacted our implementation was a feature that restricted 
our error correction lime, the host watchdog timer. A 
walchriog timer is a hardware timer on Ihe host that is set 
at I he beginning of an asynchronous operation, in our case 
an I/O operation, and cleared when the operation is com- 
plete. If the timer expires without being cleared, it sets an 
interrupt to notify the initiator of ihe operation that the 
operation did not complete. 

The Model 600/A controller's typical response to data 
errors reported from the drive is to: 

■ Send any good data that happens to be in the buffer 1o 
the host 

■ Reread the sector In error while capturing erasure flags 
and building a correction table from them 

■ Correct errors using multiple read retries ii necessary 



Matrices 



Calculate 

P-Parity Bytes 

Down Each 

Column 
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> 2 x 24 x 43 = 2064 Byte 



) 2 x 26 x 43 = 2236 Bytes 



> 2 x 26 x 45 = 2340 Bytes 



Fig. 5. Organization of the 288 EDCtECC bytes in mode 1 
sector 



Q- Parity Bytes 



Fig, 6, Computation of P parity and -partly bytes using ihe 
Reed-Sohmon product-like code. 
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■ Transfer the corrected data to the host 

■ Resume the interrupted transaction. 

During such a process, in which the host is generally in 
the middle of a DMA transfer, Lhe drive controller must 
send bytes to lhe host fast enough to ensure that the host 
does not time out the transfer and shut it down. The Model 
bOO A design constraint was one second maximum between 
bytes, 

CD-ROM drives originated in the audio world where fast 
response is not an issue. Controller communication with 
lhe drive is via a serial poll at 10.2 kbytes s k and most 
transactions with the drive can lie completed in tens of 
milliseconds* However, there is no guarantee that the drive 
will respond to a given command byte in any tiling less 
than one second. Also, the drive can take up to five seconds 
to begin transferring data on a reread, Clearly, some method 
was needed to avoid host shutdown during error correct ion. 

The solution in the Model 6007 A is to hold a sector of 
data in reserve in the controller's buffer at all times so that 
if error recovery is invoked, bytes can be sent to the host 
at well controlled intervals. With this scheme the maximum 
number of errors to correct in a call to the computationally 
intensive correction routine can then be regulated to ensure 
that the host receives a byte about every half second. The 
controller is stilh of course, at the mercy of the drive if it 
should fail to respond in a timely manner because of focus 
failure* or other mechanical problems. However, this ap- 
proach normally allows plenty of margin for the host watch- 
dog timer and provides the controller with enough time to 
do up to twenty read retries if necessarv. 

Several other features of the Model 600/A implementa- 
tion help to expedite error recovery, Wherever possible, 
computations within the ECC algorithm are replaced by 
table lookup. These include multiplications by alpha (the 
primitive element associated with the Reed-Solomon 
code), base alpha logarithm and antilogarithm calculations, 
address calculations for matrix access, syndrome associa- 
tion table indexing and shift operations during CRC 
checksumming. Also, all error table Iraversals are coded 
to minimize table reordering as errors are corrected and 
deleted from the tables. This means that tables are traversed 
from tail to head — not a revolutionary idea, but one thai 
saves a lot of time when errors can be corrected as they 
are encountered. Since it takes three or more errors in a 
row or column to prevent correction, a situation that mul- 
tiple data interleaving is designed to minimize, most errors 
can be corrected during the first pass through the correction 
table and notable reordering is necessary. As a result, large 
blocks of errors within a sector, including difficult error 
geometries* can be corrected in just over one millisecond 
per error. 

Testing and Verification 

After CIRC error correction at the drive interface, the 
CD-ROM is quite error-free. During the course of the Model 
BOO/A development, not a single data error was encoun- 
tered that was not artificially induced. Nevertheless, third 
level error correction, as implemented in the controller, is 
the final defense in ensuring accurate data transfer to the 
host and it had to be thoroughly tested to make sure that 

"A t>ardwafe problem 1 har might be caused by H dirty or damaged disk 



it performs its job properly when needed. The challenge 
we faced was how to test this error recovery algorithm in 
a relatively error-free environment. 

During the disk mastering process, errors can be intro- 
duced into any part of a sector; allowing disks to be man- 
ufactured with known error patterns on them. The Model 
BOO,.- ^ed extensively with such a disk in a test 

matrix that included all possible combinations of transac- 
tion phase, logical sector size, and error position within a 
transaction. These three system variables affect the overall 
performance of the correction algorithm, and testing these 
variables ensured that the controller could correct all error 
patterns on the disk and would behave properly under all 
error conditions. 

The test disk was designed to contain only correctable 
error patterns. Since the Model 600/A implementation 
takes advantage of erasure flags and uses the mosl robust 
iterative correction algorithm possible for the Reed- Sol- 
omon codes used in CD-ROMs, it can correct up to two 
errors in any row or column of the data matrix. It follows 
that an error pattern having nine errors that line up in three 
rows and three columns can block the correct ion algorithm. 
For the correction algorithm used in the Model 600/A, the 
probability of this happening has been calculated to be 
2*84 x 10* x p ti 9 , where P e is the probability of a random 
error at the drive interlace after CIRC. 5 This becomes an 
infinitesimal number when one uses for the value of P e the 
random byte error rate that is generally specified by drive 
manufacturers, that is, 10 ia to 10" V2 errors per bit. 

To gain some understanding of how many errors in a 
sector the Model 600/A controller can handle before unre- 
coverable errors are likely to occur, a test was developed 
that reads random sectors from a commercially available 
test disk, a TD-10 from Laser Magnetic Storage, Incorpo- 
rated, The test inserts erasure Flags and random errors at 
random locations in the sectors, sends the modified sectors 
to the Model 600/A controller, and then executes a down- 
loaded ECC routine. The only differences between the 
downloaded ECC routine and the normal run-time ECC 
routine are in the interface In the controller's buffer and 
lhe error reporting mechanism, Otherwise, the downloaded 
routine makes calls to the same modules that Mm run-time 
routine uses. The following is the unrecoverable data test 
algorithm, 

Loop 

Generate a random block address within Mode 1 region on TD-10 
Do long read of sector at random address 
Insert flags between bytes, set to no_error 
Generate random number of errors (1 * 1 20) 
For each error 

Generate a unique random location within the sector 

Generate 2 random byte error masks 

XOR the odd and even bytes at location with erf or masks 

Change ffags to error for odd and even bytes 
End for 

Write altered sector to the controller buffer 
Execute ECC download 
Log results 
End loop 

Note that errors are generated in pairs that are eventually 
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Error Detection and Correction Primer 



The concept of parity is familiar to most computer users, par- 
ticularly \t they have ever had the experience oi receiving garbled 

data cm their screen because the wrong terminal straps were 
set, or have had the message "memory parity error at ff0977a8, 
core dumped" appear on their screen and wished that last file 
had been saved more recently. 

Parity, in its simplest sense, is just the modulo-2 addition (ex- 
clusive OR) of all the bits in a transmitted codeword. This includes 
all the information bits plus a redundant bit that can be set to 
make panty odd or even. Simple parity can detect a single error 
since any one bit that changes in the transmitted codeword will 
change the parity of the received codeword. However, if there 
are two errors in transmission, parity will be restored at the receiv- 
ing end and the errors will go undetected (see Fig. 1). Simple 
parity, then, is useful only in systems in which the probability of 
error is so smalt that the probability of two errors is extremely 
small. 

Simple parity can be extended to enable not only detection, 
but also correction of single errors. If there are k information bits 
in the transmitted codewords, then tor every k codewords we 
can add a redundant codeword that is made up of redundant 
bits for each bit position in the previous codewords. In other 
words, we deal with information bits as a k X k matrix and add 
redundancy to both rows and columns. Now if a single bet in one 
of the set of k + 1 codewords changes, the parity of exactly one 
row and one coiumn of the received codeword set will be wrong. 
This locates the bit in error, which can then be changed to correct 
the error. This system is illustrated in Fig. 2. It is known as a 
product code and is guaranteed to be able to correct single 
errors and detect double errors within the set. 

Another method of detecting and correcting errors is to use a 
linear block code. These codes, known as (n s k) block codes,, 
have codewords that are n bits Jong r containing k information 
bits and n - k redundant bits. Without going into great detail, 
these codes consist of codeword vectors, C, that are obtained 
by multiplying the information vectors, I, by the k x n generator 
matrix, G, that is, C = IxG The generator matrix creates the 
bits to add for parity. The received codeword vectors, R, are 
assumed to be the sum of the transmitted vectors and an error 
vector, E, so that R = C + E Associated with the generator 
matrix, and algebraically related to it in a specific way, is a parity 
check matrix, H, which has the nice feature that for all codewords, 
C x H = 0. An added attraction that arises from this fact is that, 
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Fig. 1, Simple parity example. 
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Fig. 2. Product code parity example. 

if S = R x H does not equal zero, it contains information 
to locate and correct errors jn the received codeword because 
S - (C + E) x H - (C x H) + (E x H) = + E x H and E 
x H contains the error correction information. S is known as the 
syndrome vector (a vector that is the result of a parity check), and 
its power to detect and correct errors depends on the number of 
redundant bits in the code. A Hamming linear block code is 
illustrated in Fig. 3, 

One characteristic of mass data storage is that it is usually 
byte-oriented, at least at the controller and interface levels. Codes 
can be built on finite fields other than the binary field, and the 
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Fig, 3. A Hamming (7,4) linear block code. 
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' Bytes Containing Error Data 

Fig. 4. Time-domain interleaving example 

codes used in optical media, Reed-Solomon codes, are con- 
structed on [he Galois field GF(256) or GF(2*), a field of 256 
symbols. Generator and parity check matrices are constructed 
differently than for linear block codes, but are used In much the 
same way However, codewords consist of n 8-bii symbols rather 
than n bits, and all arithmetic is done moduJo-256 rather than 
modulo-2. Decoding and correction are more complex than for 
linear block codes, but the principle is the same 

Basically, the Reed-Solomon codes are effective on random 
byte errors. However, errors in the mass storage environment 
tend to occur as bursts across multiple bytes To help alleviate 
this problem and make the codes more effective, one further 
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Fig. 5. Spatial inter having example. 

technique is used on optical media. This is catted interleaving. 

On CD-ROM media, data is time shifted and interleaved as it 
goes into the channel (ie., as it is mastered). Note in Ftg, 4 how 
any n-symbot burs! can be fully corrected with a single error 
correcting code since any given codeword has only one error 
in it A different method is employed on magnetooptical media. 
Here every nth symbol in the data stream is used to form one of 
n codewords This turns out to be more of a spatial interleaving 
as illustrated in Fig. 5. These interleaving techniques tend to 
randomize burst errors and extend the effectiveness of the cor- 
rection codes. 
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distributed to the odd and even correction matrices. This 
si inulates drive hardware that can only detect errors within 
di-bytes* and can only create erasure Hags for byte pairs. 
Fig. 7 is a graph of the results nf one test run that performed 
25,150 passes through the loop, The number of errors on 
the < axis is the number of error pairs that were generated 
tin t !c jch 2048-byte sector. These results show that there is 
still a ninety percent chance of correcting sectors that have 
ten percent data corruption. 

What dues this mean to the user? These error simulation 
results indicate that disks with byte error rales as high as 
ID' 1 after CIRC still have a very good chance of being read 
correctly on the first pass through the error correction 
routine. Since its overall error recovery effort also Includes 
multiple read retries that attempt to fill in the blanks on 
sectors that are unrecoverable, thi.i Model BOO/A offers the 
user the maximum in error recovery for CD-ROM technol- 
ogy- 
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Fig.. 7. A graph resulting from 21,150 passes through an 

unrecoverable data test algorithm. The graph shown the prob- 
ability ol unrecoverable data based on the number of errors. 
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Providing Software Protection Capability 
for a CD-ROM Drive 

The HP Series 6 1 00 Model 600/ A drive supports two levels 
of security for software protection: load-time security, which 
prevents loading a package without the proper authority , 
and scrambling data on the disk to prevent reading a 
protected disk with another CD-ROM reader, 

by Kenneth FL Nielsen 



AN EFFECTIVE USE of CD-ROMs is for the distribu- 
tion of very Large quantities of software and litera- 
ture. Before CD-ROM technology, software updates 
were distributed on tape, This method required the creation 
of multiple customized tapes for each customer. The tapes 
contained only the software that the customer had pur- 
chased. The security solution with this method was sim- 
ple — customers only received tapes for the packages they 
had purchased. 

With CD-ROM as the distribution medium, many large 
software packages can fit on one disk. This capability pro- 
vides a significant cost savings over the tape distribution 
method. The problem with using CD-ROMs for distribution 
is how to give customers many software packages on one 
disk yet restrict them from using software that they did not 
purchase. This article discusses some aspects of the HP 
Series 61 00 Model BOO/A CD-ROM drive security scheme, 

Implementation Considerations 

Two security schemes were considered for the HP Model 
600/ A: run-time security iind load-time security. Run-time 
security requires each package lo check the system that it 
is about to run on- If the system is approved for running 
I he package, the package will continue to run. If the system 
is not approved, the package will shut down T not allowing 
the package to run on a system that it was not originally 
installed on. Run-lime security would have been a good 
method if we did not have the constraints of having to run 
on existing systems that do not have a method of identifying 
themselves, and protecting software that cannot be easily 
modified to use run-time security. 



Load-time security does not allow the customer to load 
a package from the disk without the proper authority. This 
is the method we decided lo use for the Model ftOuYA. This 
method satisfies both of the constraints mentioned above. 
The authority for accessing packages on an HP CD-ROM 
is a unique password that is shipped to the customer with 
each disk. This password enables customers to identify 7 
themselves uniquely to the Model 600/ A CD-ROM drive. 

Security Toolbox 

There are many opinions on and methods of implement- 
ing software security features. 1 ~ If we had provided a soft- 
ware security method that software distributors had to use. 
we would have ended up with a very small number of 
users. Instead, we decided to implement a toolbox ap- 
proach, This gives users a box of security tools that can be 
used independently or nnl used at alL 

The tools provided in the toolbox include: 

■ The capability to lock and unlock discrete portions of 
the disk selectively 

■ The ability to unscramble or decode secured data 

m The ability to provide the host with a unique identifier. 

The security scheme implemented may be defined in the 
sin urity information that goes on the disk when it is mas- 
tered. This information [nay also define which host-to-disk 
commands (Command Set 8U commands) the Model 600/ A 
will accept from the host. 

The security information for a disk is located in the disk's 
system area. When a disk is mounted in I he drive, based 
da the information in the system area, the Model 600/ A 
either forces Ihe implementation of the security scheme or 
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redefines the default values of certain para meters. The dc- 
iriult values are used when s now disk is loaded and after 
a Security Clear command is received from the host. 

Region Access Map 

The capability to lock and unlock regions uf the disk 
selectively is provided using a Structure Called a region 
access mop, which is located in the system area of the disk, 
The region access map logically divides I he disk into re- 
gions, Each region has one or more togicai sectors and each 
region is assigned to a group. Several different regions may 
he assigned to one group, but a region can only be assigned 
to one group. Fig. 1 shows this organization. Each region 
access map entry contains the start address of a region and 
the group the region Is assigned to. 

A structure called a group access mop is used to deter- 
mine which groups to lock or unlock. A default group 
access map exists in the system area of the disk. The group 
access map is a siring of bits with the value of each bit 
representing ihe default locked or unlocked slate of each 
corresponding group. Groups that are available to everyone 
will normally have their default value unlocked, Croups 
that must be individually purchased will normally have 
their default value locked. 

For the customer to modify the group access map to 
unlock purchased packages, a group access map with the 
appropriate group representations set to unlocked and a 
veritication password must he sent from I he host lo the 
Model 600/A disk controller. The disk controller will do 
some manipulation on ihe group access map, the publica- 
tion identifier from the disk, and the internal identifier of 
the disk controller. The result of the manipulation is com- 
pared with the verification password received from the 
host. If the comparison proves that the group access map, 
the disk , and the disk controller all belong together, the 
customer's group access map is accepted as defining the 
locked and unlocked groups on the disk. II not, I he HP 
Model GOO/A disk controller will use the default group 
access map located in the system area of the disk. Fig. 2 
summarizes this process, 

To keep anyone from setting up a computer and sending 
a variety of verification passwords al fuJl machine speed 
with the purpose of breaking through the security mecha- 
nism, the Model GOO/A will purposely delay one second 
before returning to the host after discovering an incorrect 
password. 

Fig. 3a shows a typical group of files that might exist on 
a software distribution disk. The operating system is con- 
tained in logical sectors through 500, the COBOL com- 
piler in sectors 501 through 600, and the Pascal compiler 
in sectors 601 through 700. Because of the modularity of 
the Pascal and COBOL compilers, both use drivers located 
in sectors 701 through 750. The region access map contains 
the disk addresses of each file. All the operating system files 
are assigned to group 0, the nonshared part of the COBOL 
compiler to group 1. the nonshared part of the Pascal com- 
piler to group 2, and the shared drivers to group 3. 

If all customers were allowed access to the operating 
system but not the COBOL or Pascal compilers, the default 
group access map would have bit P representing group 0, 
set to unlocked, and bits 1, 2, and 3, representing groups 



1, 2, and 3 respectively, set to locked [see Fig. 3b), If the 
customer had purchased COBOL but not Pascal, the cus- 
tomer's group access map would have bits 0,1, and 3 set 
to unlocked and all other bits, including bit 2, set lo locked 
(see Fig. 3c). Because there may be hundreds of software 
packages on a disk, it would be easier if the customer did 
not have to lype in the group access map each time the 
system needed to be updated. Therefore, the group access 
map is not scrambled (encoded), allowing the customer to 
modify the map after receiving permission to access new 
packages. Allowing the user to modify the group access 
map does not nullify the security scheme because the group 
access map and Ihe verification password must be compat- 
ible, ensuring that the customer can unlock only purchased 
sol I ware. 

When the customer tries to access the disk, a host pro- 
gram will ask the customer for the password that came 
with ihe disk. The program will send the group access map 
and the password to the Model 600/A disk controller, and 
after performing the comparison process d escribed earlier, 
the controller will unlock the correct portions of the disk, 
Once the disk is unlocked, it can be read using any standard 
CS-fiO driver. 

If the hosl does try to access a locked portion of the disk, 
the Model 600/A will normally respond with a NO DATA 
FOUND fault. However, there are some system drivers that 
will abort if this occurs, To solve this problem the Model 
600/A is also capable of not res po riding with the NO DATA 
FOUND fault and returning to the host a string of meaning- 
less data to complele ihe transaction so that it seems as if 
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Fig. 3. (a) A typical group of fifes 
on a software distribution disk and 
their group associations, (b) 
Group access map showing that 
the customer has access to the 
operating system but not the 
COBOL or Pascal compters (c) 
Group access map showing that 
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operating system, the COBOL 
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nothing happened. (The CS-80 command Data Fill, which is 
described later in this article, provides this capability J. The 
host can then inquire about the security status to find out 
if an attempt was made to access a locked region of the 
disk and that invalid data was transmitted. 

Unscrambling Data 

The; lnckable disk is only secure if it is mounted in the 
Model 600/ A CD-ROM drive. To prevent reading the disk 
from another CD-ROM reader, the data on a distribution 
disk is scrambled. The Model GOO/A can unscramble a disk 
thai has its data scrambled, This option should protect the 
packages from being loaded via anolher reader, and pro- 
vides an extra level of security on lop of the group access 
map and the veril'ii ntiori password. 

When data is scrambled for security purposes, a de- 
ciphering key is also generated. The unscrambling al- 
gorithm will return the scrambled data back bo readable 
data only if it has available the same key used in the 
scrambling algorithm. The Model 600/A's unscrambling 
algorithm is located on the drive's controller board (see 
page 40), The key for the Model B0Q/A is an 8-byte value 
that can be located either on the disk or sent from the host. 
If the key is on the disk and scrambled, it is decdoded 
using a predefined algorithm. If the key is sent from the 
host, the key will be decoded using an algorithm that is 
unique to efich customer's Model 600/ A CD-ROM drive* 
This scheme allows each of several customers to have a 
unique key even if they all have access to the same data. 

The security tool tor unscrambling data can be used in 
different ways, One method unscrambles either the whole 
disk or selected portions of the disk when data is read from 
the disk and .sent to the host. Another method involves the 
host's using the Model 600/A as an unscrambling box. This 
method can be used only if certain portions of a package 
are scrambled. If the key used to unscramble the data is 
on the disk T the default method is to unscramble all data 
as it is read from the disk (see Fig, 4 switch position 2). If 
the key is sent from the host, the default method is to read 
the data and leave it scrambled (see Fig. 4 switch position 
3). 



To use the Model 600/A as an unscrambling box the host 
reads a complete scrambled file from the disk and then 
sends a customer-unique deciphering key to the CD-ROM 
drive. The host's unscrambling algorithm is a write, un- 
scramble, and read sequence. First I he scrambled file is 
written lo the data buffer on the Model 600/A's controller 
using the CS-80 command Write Butter (see Fig. 4 switch 
position 4), Next, using the CS-80 command Unscramble Buf- 
fer the host commands the controller to on scramble the 
data in the buffer using the deciphering key passed down 
earlier (see FLg + 4 switch position 1), Finally, the host uses 
the CS-80 command Read Buffer to transfer the unscrambled 
contents of ihe controllers data buffer Lo host memory. 

Unique identifier 

If a customer wants to implement run-time security, the 
Model 600/A has an 8-byte serial number available for the 
host. The serial number is in Ihe same packed format as 
bytes two through nine of the HP 46084A HP-HIL ID mod- 
ule. 1 This is the module used for system identification 0B 
IIP <JOO0 Series riOCJ systems. The definition of the Model 
60U/A's 8-byte unique identifier corresponds to the report 
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Fig. 4. Steering unscrambled data in and around the Model 

600/A's unscrambfer, 
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security Code definition of bytes two throogh riMg oi thti 
ID module. 

Command Protocol 

The HP-IB Command Sot 80 protocol is used for com- 
munication between the CD-ROM reader and the HP HOOD 
MPtt VE operating system, To simplify integration and for 
initial system startup the Model 600/ A looks like a w rite- 
protected HP 793 5 A 300-megabyte disk to the HP 3000 
MPE VE operating system. 

Making the Model 600/A look like a write-protected HP 
7935 A in most res peels was simple. The biggest problem 
was trying to support the Release command, which frees a 
disk to lie removed from the drive. Without a button on 
the front panel of the Model 600/A, the customer cannot 
request that the disk be released. On the HP 7935 A, if the 
customer wants to remove a disk, the front-panel release 
but tun is pressed and the HP 793 5 A executes a release 
sequence thai essentially asks the host if it can release the 
disk and go off-line, allowing ihe user to remove the disk 
and replace it with another disk. The HP 3000 system rec- 
ognizes this sequence and knows that a disk has been re- 
moved and possibly replaced, 

On the Model 600/A t if the door is unlocked, the user 
can remove a disk caddy at any time. It would be meaning- 
less to make a Release request to the host because If the 
host denied the request, the host would think that the same 
disk was still loaded. The solution to this problem is that 
when a disk is removed a report is sent to the host th;it ;i 
new disk of zero length has just been loaded, 

The constraint of trying to look like a write-protected HP 
7935 A meant that commands specific to the security or 
audio leal ores of the CD-ROM had to be added under the 
CS-80 Initiate Utility command. 

Service 

Servicing the Model 600/A posed a potential problem. 
Since each unit must have a unique serial number that is 
used to validate passwords and manipulate unscrambling 
keys, the service engineer must have a means of program- 
ming these numbers in the field when a CD-ROM drive's 
controller board is replaced. The alternative to this would 
be to return the unit to the factory for repair. 

Every repair board has programmed in EEPROM the se- 
rial number REPAIRED and a special seed that is used to 
generate a unique password verification number. If this 
serial number is present on a board, the Model GOO/A will 
allow a special service command (Service I] to be executed 
thai programs a serial number into the controller board's 
EEPROM. it will also cause the unit to derive and program 
a unique password verification number into the EEPROM. 

If the service engineer discovers after programming the 
controller board that the original controller board should 
not have been replaced, there is a process to return the 
repair controller board serial number back to REPAIRED* 
The process requires that a special disk be mounted into 
the drive before a second special service command (Service 
tr) Is executed. The combination of the special disk and the 
bytes sent with the Service II command will reprogram the 
serial number REPAIRED and the special seed back into the 
controller board's EEPROM. 11 the Service II command is 



attempted and proves to be an invalid command because 
the wrong disk is being used or the wrong bytes are sent 
to the Model 600/A, the controller will either program the 
EEPROM incorrectly or erase the EEPROM, requiring it to 
be sent bat:k to the factory for reprogranimin£. 

Utility Commands 

The utility commands are CS-80 commands developed 
In support CD-ROM capabilities, security toolbox func- 
tions, and status information relevant to the Model 600/A 
security scheme. These commands are Implemented via 
the CS-80 Initiate Utility command. The Initiate Utility command 
was included in the original CS-80 definition to allow the 
implementation of commands that are not in the formal 
CS-80 definition but fit into the CS-80 protocol. 
CD-ROM Commands. The following CS-80 commands are 
designed to support the Model 600/A and the features of 
CD-ROMs. 

fl Door Lock, Lock the drive's media door to prevent un- 
wanted removal of the disk. 

■ Door Unlock. Unlock the drive's media door to allow re- 
moval of disk. 

■ Play Audio (length of play) (address of audio portion of the disk 
where to start playing). Play an audio portion of the CD-ROM. 
This command will return to the report phase when the 
audio is finished, 

■ Play Audto With Return Address (length of play) (address of audio 
portion of the disk where to start playing). Play an audio portion 
ol Ihe CD-ROM. This command will have multiple 
execution phases. At the end of each execution phase 
the address that is currently playing is returned to the 
host. 

■ Read TOC (track number). This command will return the 
TOC (table of con I en Is) entry for the desired track 
number. The entry returned will consist of the address 
of that track and the control and address field from ftfce 
Q channel of the CD-ROM. 

■ Set Logical Sector Length (sector length). This command will 
modify the logical length of a logical sector. The options 
available are 256, 512, 1024, 2048. 2336 and 2352 bytes. 
The default sector length will be either 256 bytes or the 
length defined in the system area of the disk. Ihe typical 
frame of an industry-standard CD-ROM written with 
computer data contains 16 bytes of header, 2048 bytes 
rj| data T and 288 bytes of error correcting code (ECC). 
The 256, 512. 1024 and 2048-byte sectors will return 
data from the data field, If the disk has data for whirl] 
data integrity is not important (e.g., video data), the ECC 
field may be replaced with 288 bytes of user data. The 
2336-byte sector length will return all 2336 bytes of data 
[the full sector minus the header field], The 2352-byte 
length will return the full sector. Ii the CD-KOM is a 
secured disk T this command is disallowed. 

Security Toolbox Commands. These are the CS-80 com- 
mands that implement the security scheme for the Model 
600/A, 

■ Data Fill (enable disable)(fill word), This command will either 
enable or disable the data fill capability. If data fill is 
enabled when a locked region of the disk is encountered, 
tlie fill word will Finish the rest of the current transaction 
and the NO DATA FOUND fault is not set. If data fill is 
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disabled, the current transaction will abort when a 
locked region of the disk is encountered and the HO DATA 
FOUND fault is set 

■ Unscramble Buffer (length of data M address in buffer where to start), 
This command will cause the Model 600 A controller's 
data buffer to be unscrambled with the key thai is cur- 
rently loaded in the controller's unserambler [Fig- 4 
switch position I). 

• Unscrambled Read (on off). This command will either send 
the data stream from the disk through the unscramb 
algorithm (on) or not (off) before sending the data to the 
host (Fig. 4 switch positions 2 and 3). 

■ Read Buffer (length of data) (address in buffer where to star!). 
This command will cause the contents of die controller's 
data buffer to be returned to the host. 

■ Receive Data Unscrambling Key (key). 

This command will cause the key received to be manipu- 
lated by the Model BOO/A's unique identifier algorithm 
and then be used as the unscrambling key for future 
unscrambling. 
m Receive Group Access Map (password) (group access map). This 
command will cause the received ^mup access map to 
be accessed if the password, the group map T and the 
currently loaded CD-ROM's idenlifier all belong to- 
gether. 

■ Return Drive Security Number, This command will cause the 
Model BDO/A's compacted serial number to be returned 
to the host. 

a Wnte Buffer (length of data)(address in buffer where to start). This 
command will cause the Model 600/ A's data buffer to 
be written into by the host (Fig. 4 switch position 4), 
Security Status Commands. The foil owing commands were 
added to retrieve status information about I he CD-ROM 
and to make the security toolbox easier to use. 

■ Report Security Quick Status. This com m and will return one 
byte that indicates powerfail, disk change, anuVor a se- 
curity fault. This status Is cleared either by a Security Clear 
command or by the execution of the Request Security Status 
command. 

■ Request Security status. This command will return a string 
of bits indicating the type of disk currently loaded, the 
security features that are present in the system area of 
the disk, and ihe security faults that have occurred. This 
status is cleared either by the Security Clear command or 
by the execution of the Request Security Status command. 

■ Security Clear. This command will cause all security fea- 
tures to return to their default state. The CS-80 Clear 
command will not affect the security features, The differ- 
ence between the CS-80 Clear command and the Security 
Cfear command is that the CS-80 Clear command will set 
the CD-ROM reader and all internal state machines back 
to power-on conditions. Ihe Security Clear cum man d will 
set the security features back to either power-on or new 
disk loaded conditions. Using the Security Clear and the 
CS-SO Clear commands independently will help ensure 
that no data corruption occurs. 

» Set Security Status Mask. This command will prevent ibe 
occurrences I ha I are masked from affecting the Security 
Status or Security Quick Status commands. 



Conclusion 

The tools designed into the HP Series 6100 Model 6Q(jVA 
HP-IB CD-ROM drive should be adequate for almost any 
user who wants to distribute software or data on CD-ROM 
disks. The disk publisher can tailor the security level to 
range from no security dt all to a very complex security 
scheme. If the host system wants to build a security driver 
with a protocol that is similar to the host C5-80 driver, the 
commands are available to do so. If the disk distributor 
wants to change the unique customer password verification 
number, there are hooks built into the Model 600/A to 
allow that change to be done safely at the customer's site. 
Essentially, ihe Model 600/A security scheme provides a 
good balance between security and ease of implementation 
for both the distributor and the customer. 
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Support for the ISO 9660/HSG CD-ROM 
File System Standard in the HP-UX 
Operating System 

To allow HP-UX users access to CD-ROM files, the ISO 
9860/ HSG file system format standard has been 
incorporated into the HP-UX 7.0 operating system. 

by Ping-Hui Kao, William A. Gates, Bruce A. Thompson, and Dale K. McCluskey 



THE CD-ROM IS a very cost-effective and versatile 
electronic distribution medium. It provides large ca- 
pacity (600 Mbytes), longevity, low cost T multi- 
media (audio/video) capability, read-only protection, and 
random accessibility. 

The ISO 9660 standard 1 and the High Sierra Croup (HSG) 
working paper describe file system formats for publication 
and distribution of information mi CD-ROM media. CD- 
ROMs and the ISO 9660/HSG standard have become well 
established in the MS-DOS environment. Currently, there 
arc large amounts of personal computer software distrib- 
uted on CD-ROMs. Microsoft's MS-DOS CD-ROM cxtcn- 
sinns J ' 4 provide the capability to access files on CD-ROMs 
in the UNIX* environment* 

This paper describes HP's design* implements! inn t and 
support lor I he ISO 9660/HSG CD-ROM file system in I he 
HP-UX 7.0 operating system kernel. The CD-ROM file sys- 
tem is an implementation of MS-DOS CD-ROM extensions 
on HP-UX operating systems. After mounting a CD-ROM 
that adheres to the CD-ROM file system standard, files on 
the CD-ROM are accessible through normal HP-UX system 
calls and commands, allowing users and application pro- 
grams to take advantage of the high capacity and low du- 
plication cost of this medium without the need for any 
special programmatic interface. 

Design Goals 

The primary objective of incorporating the ISO 9660/HSG 
CD-ROM file system into the HP-UX operating system was 
to provide easy access to this new medium so that applica- 
tions including HP product distributions could take advan- 
tage of CD-ROM technology. Based on this and other objec- 
tives the design goals for the CD-ROM project included: 

■ Mounting. The user must be able to mount ISO 9660/HSG 
file systems under the HP-UX system. The files on the 
CD-ROM are then accessible through normal HP-UX 
commands and system calls like those on the HP-UX 
native high-performance file system (HFSj. 5 The user 
must also be able to mount other file systems such ws 
the network file system (NFS) under directories in the 
CD-ROM file system. 

■ Networking. Files on an ISO 9660/HSC-compatible CD- 
ROM must be accessible via supported networking ser- 

*UNlX i$ a regtsierod trademark ot AT&T m The U S A and other countries. 



vices such as NFS and RFA [remote file access — an HP- 
proprietary ii el work service for file accessing). 
Application Programs, An application program that is 
functional in a read-only mode in an HFS environment 
must also be functional in a CD-ROM file system environ- 
ment unless it is dependent on some features of the HFS. 
ISO 9660 versus HSG. Although the LSO standard is the 
official CD-ROM file system format standard, many older 
CD-ROMs conform to the format defined in the HSG 
working paper. The HP-UX must hide any differences 
between these two formats from the user 
Adherence to HP's Diskless Semantics. One of the major 
features in HP's implementation of diskless workstations 
is that all diskless clients in a cluster have the same view 
of files on all mounted file systems. This feature must 
be preserved with the addition of the CD-ROM File sys- 
tem. 

Performance, The I/O transfer rate should be as close to 
a CD-ROM drive's maximum rate [150 kbytcs/s) as pos- 
sible when the benefits from buffer caching are excluded. 
The number of disk seeks must be minimised, File sys- 
tem buffering and path name caching must be used to 
help overcome the transfer rate and seek time (up to 1 
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Fig. 1. The ISO 966Q/HSG data layout on a CD-ROM disk. 
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s) limitations of CD-ROM drives. 

■ Configurability. Provide the user with the capability to 
remove CD-ROM-f ile-system-specific code from the ker- 
nel if it is not required. 

■ File execution. Programs recorded on an ISO-9660 HSG 
formatted CD-ROM must be able to be executed directly. 
Executable files in demand-loaded form should be 
executable as well as shared text executable** and regular 
executable files. 

■ Level of Implementation. The resulting implementation 
must conform to level 1 implementation and level 2 
interchange according to ISO 9660, These levels spc 
that access is limited to a file system thai is described 
by a primary volume descriptor and that contains single- 
m -Hon files. Single-section files and volume descriptors 
are described later. 

» Quality Implementation. The CD-ROM file system code 
must have good quality and he easy to maintain. Tech- 
niques, such as structured design, should be used to help 
achieve this goal. 

ISO 9660 HSG CD-ROM File System 

The overall data layout for an ISO 9660/HSG CD-ROM 
file system is shown in Fig. 1. There are typically four 
sections in this layout: system area, volume descriptor, 
path table, and directory and file data. The system area 
and the vol nine descriptors must occur in the order shown. 
System Area. This section makes up the first 16 2048-byte 
blocks on the media. It is reserved for storing information 
to boot a system, the secondary loader, security keys, and 
other system data supplied by the disk preparer. 
Volume Descriptor. This section typi" :..ill\ contains one 
primary volume descriptor and zero or more supplemen- 
tary volume descriptors. Each volume descriptor describes 
the ril tributes and structure ol a directory hierarchy on the 
CD-ROM. The list of volume descriptors is terminated by 
a volume descriptor terminator. These volume descriptors 
allow multiple directory hierarchies to exist on a single 
volume (i.e., a physical CD-ROM], or a single directory 
hierarchy to span multiple volumes. 
Path Table. This section contains the path tables for all 
the directory- hierarchies on the CD-ROM, Each record in 
the path table contains iniu filiation that enables the system 
to locate the directory it describes. The path tables do not 
have to he placed together as shown in Fig. 1. They can be 
placed anywhere on the disk in whatever manner is accept- 
able to the data preparer. This is often done to minimize 
disk access limes. 

Directory and File Data. This section contains the directory 
and file data for all the directory hierarchies on the CD- 
ROM, A directory contains records that describe directories 
or file sections [described later). Directories are described 
by two directory records [see Fig. 2]. The first record de- 
scribes the parent directory. The second record and a record 
in the parent directory describe the directory itself. Fig. 3 
shows the structure of a directory record. 

A tile is divided into pieces called file units which are 
recorded with file unit gaps between them. For perfor- 
mance, the sizes of file units and file unit jjaps can be 
selected to maximize disk read speed. A file can also be 
divided into file sections* Each file section has its own 



directory record. All file sections for the same file must all 
share the same filename. File sectioning allows a file to 
span multiple volumes. 

An optional data structure called an extended attribute 
record can be used to specify additional information about 
Ble or directory with which it is associated. An ex- 
tended attribute record contains information such as the 
owner and group identifiers, access permissions, and cre- 
ation, modification, expiration, and effective dates and 
times. The extended attribute record of a file or directory 
is recorded before the data of the Hie or di r -e Fig. 4). 

CD-ROM File System Design and 
Implementation 

The structure of the HP-UX file system is based on the 
abstraction of file systems and file system operations re- 
ferred to as the vnode layer. The vnode layer was introduced 
by Sun Microsystems lnc. h This structure supports the ad- 
dition of new file systems in the UNIX environment. The 
vnode layer had been added to the HP-UX system to support 
non-HFS file systems (see Fig 5), Given that it was already 
in place, it seemed logical to implement the CD-ROM file 
system under the vnode layer. The advantages of this ap- 
proach are: 

■ Modularity* The part of the kernel that supports CD-ROM 
file systems can be easily separated from the other parts 
of the kernel. 

■ Interoperability. The CD-ROM file system can easily 
coexist with other supported file systems like NFS be- 
cause CD-ROM files on an NFS server are made available 
to NFS clients, 

■ Integration. Other file systems can be mounted on CD- 
ROM directories. This provides I he capability of updat- 
ing a direclnry in a CD-ROM by mounting a floppy disc 
on the directory. Also, additional CD-ROMs can be 
mounted on a directory to create a large directory hierar- 
chy that mi^hl exceed the capacity of a single disk. By 
mounting these CD-ROMs on different directories the 
user can have different configurations of the directory 
hierarchy. 

■ Resource sharing The CD-ROM file system can share 
system resources (e,g,- buffer management, name cache, 
drivers, etc.) with other file systems. 

At the vnode layer each file has an associated data slim- 



Records for 
Directory C 



Records for 
Directory B 



Fig, 2. The association between directory records and direc- 
tones and files. Each directory is assigned two directory rec- 
ords , one record for the directory ttself and the other for sis 
parent. 
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Fig, 3. The contents of an t$0 Q660iHSG directory record 

ture nailed a vnode. This Is a generic data structure used by 
all the supported file system types lo describe attributes 
about a file. One entry in the vnode is a pointer fco a tile 
system-dependent data structure. Information needed by 
the specific: file system implementation is siored in I his 
structure. 

The higher-level layers of the kernel operate on vnodes 
rind low-level file-system-specific operations are encapsu- 
lated in separate modules. For example, the main part of 
tin 1 kernel does not know about the CD-ROM file system 
because that knowledge is encapsulated in the CD-ROM 
file system code 

CD-ROM File System cdnode 

In the HP-UX high-performance file system, each file has 
an associated data structure called an inode. which resides 
on the disk- Each inode is assigned a unique number by the 
system and the structure contains information such as file 
ownership, Hie type f internal representation, access per- 
missions, and other data that the system uses to perform 
operations on a file. In the CD-ROM file system a system 
dependent pointer in the vnode points to a structure called 
a cdnode. A cdnode structure stores information similar to 
that found in an inode but specific to the CD-ROM file sys- 



Extended Attribute Record 



File Unit Gap 1 




tern. Unfortunately, inode-like structures vvith unique num- 
bers do not exist in the ISO 9660/HSG file system. There- 
fore, cdnode information must be created using directory 
records and extend ed attribute records. If a file does not 
have an extended attribute record associated with it, some 
of ihe fields in a cdnode contain default values, 

A unique number similar to an liFS mode number had 
lo be defined for the cdnode. Our solution was to use the 
disk address of the direolory record for each directory as 
the cdnode number. This number uniquely identifies a file 
or directory because the ISO 9660/HSG format does not 
support multiple links. In addition, this solution also pro- 
vides us with the ability to locate the directory entry with- 
out any extra calculation, 

We encountered one difficulty with using the disk ad- 
dress of the directory record to represent the cdnode 
number — deciding which directory' record to use. A direc- 
tory can be referenced from three locations in the directory 
hierarchy: from the directory itself (the 'V 1 entry] . from a 
subdirectory (the "•„" entry), and from a record in its parent 
directory (see Fig. 6). We determined early that we could 
not use the disk address for the directory enlry '*.. r to 
identify the directory uniquely because there can be many 
subdirectories. The choice between using the disk address 
for the "," entry and the directory entry in the parent direc- 
tory was not obvious until the case of resolving the 
pathname for the entry ".," was considered. If the reference 
from the parent directory is used, at least three reads of 
differenl directories are needed to perform a pathname 
lookup of the 'V entry. For example, in Fig, 6 if the current 
directory is /cdrom/usrUb and we want to locate the cdnode 
number for directory cdrom/usr, the three reads would be: 

■ Read the ".." entry of the current d tree lory lo get the 
location of the parent directory. 

■ Read the "„" entry of directory /cdrom/usr to get the loca- 
tion of directory cdrom t the grandparent directory. 

■ Read I h rough direclory cdrom to locate an entry that 
matches directory reference /cdrom/usr. The disk address 
of this entry would be the cdnode number for directory 





■ 


System Calls 


7r¥?J 


■ 




1 


■■ 

■ 


P| 


■ 


aj „". & i- 




aaai 


1 




1 


vnode L*yw 


"V%i 


I 




' aaai 


■ 


■ ■ 


B 


■ I * < ^^^H 




1 ■ ~~ 1 


El 


MM • 


m 


High-Performance ISO 9660 HSG 
File System (HFS) CD-ROM File System | 


Network File MF< * c 




System (NFS) Whb * 


Server 


■ 


| J 


1 II 1 


■ 


Device Drivers 


■ 


Network 



File Unit Gap n 



File Unit n 



C m 



Fig. 4. A file section record. 



Fig. 5, The vnode architecture. 
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cdrom usr. 

It is much simpler to use the disk address of the directory 
record '" "as the cdnode number to obtain thecdnode number 
of **..". With this scheme the only operation needed 1$ to 
read the directory entry ik ./ T and from it the location of the 
parent directory can be calculated easily, hi our implemen- 
tation the cdnode number of the parent directory is stored 
in the cdnode whenever possible to reduce the number of 
read operations. 

Pathname Lookup 

One operation the kernel performs frequently is the reso- 
lution of pathnames. Name resolution is traditionally done 
one pathname component at a time to provide proper han- 
dling of mount points. With the advent of different file 
system types, traversing the pathname has become even 
more complicated. 

Each vnode is defined by a uniqiu; file system type 
specifier and a set of services required by HP-UX semantics. 
To perform a pathname lookup on a vnode, the pathname 
lookup function for lhal file system is called (e.g., rrfs_ 
lookup), returning the vnode for the next component. If a 
mount exists on this vnode T then changing file systems Is 
indicated, perhaps to one of a different type. The vnode of 
the root directory for the new file system is obtained. This 
vnode may contain differed file system dependen! functions 
than the previous vnode. The functions at the new vnode are 
used to continue the pathname lookup process until all 
components have been parsed, Thus, each file system is 
allowed to handle its own directory searches, and mounting 
different file systems on arbitrary directories is possible. 

Because of the long execution path and the slow disk 
seeks, the scheme above could be very time-consuming. 
To help with this, the directory name lookup cache, a fea- 
ture that comes with the vnode layer, is used. It caches 
frequently used pathname elements and their vnode point- 
ers. This significantly reduces the amount of redundant 
disk accesses made during pathname lookup. 

The ISO 9660/HSG formal provides a supporting data 
structure called a path I able that is included for pathname 
lookup. The path table describes the entire directory struc- 
ture of a file system, This allows traversing the entire 
pathname with one seek to avoid tin: lengthy seek time of 
CD-ROM drives. This method does not allow checking of 



mount points during the traversal. The path table can be 
very large, and could consume a large amount of the avail- 
able memory if kept in main memory entirely. If the path 
table had to be referenced from the disk, much of its poten- 
tial benefit would be lost. Although not ideal, most of the 
path table's performance gain is already provided by t he- 
directory name lookup cache mentioned above. For these 
reasons, path tables are not nsed for pathname resolution 
in our implementation. 

Backward Compatibility 

One major design goal was to minimize the impact on 
application programs. The strategy to achieve transparent 
access to the CD-ROM file system was to map, as much as 
possible, the characteristics of ISO 9660/HSG ooto standard 
HP-l 'X semantics and characteristics. '1 "he first area of con- 
cern was the directory library routines because the CD- 
KOY1 file system directory entries are tpnte different from 
those of the HFS. HP-UX routines use the system call get- 
direnthes to obtain directory entries in a file system indepen- 
dent way. When getdirentries is used to read a CD-ROM file 
system directory, the fields of the directory records are 
mapped into the format of a standard HFS directory entry. 

Another potential problem area was the system call stat, 
which returns inode information for a file. To preserve the 
bbfei I Cpde compatibility Cfl existing compiled programs, 
the stat structure used to return inode information was not 
i hanged. When stat is used for a CD-ROM file, information 
about a file that maps well into the stat structure is passed 
back and other items specific to ISO 9660/HSG formats, 
such as file unit size, interleave gap size, and so on are 
dropped. To obtain the data that does not map well into 
the slat structure, a new system call fsctl [file system control) 
was created. Standard HP-UX file attributes, such as user 
identifier, group identifier, and permissions are optionally 
specified in ISO 9660/HSG in an extended attribute record. 
For files without an extended attribute record, the user 
identifier and group identifier are simply set to an out ot- 
range number and permissions are set to 0555 [readable 
and executable by everyone as specified in the standard). 
Fsctl allows retrieval of information specific to any file sys- 
trin. The reason we rejected the idea of using the system 
command ioct! in favor of fsctJ was that ioctS is intended lor 
cuulrol of special devices. 
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Design and Development Obstacles 

During the design and development of the features lo 
suppnrl the ISO Hohll/HSO standard, the following obsta- 
cles had to be overcome, 

Disk Block Size. The kernel's buffer management scheme 
requires I ha I all file system blocks be accessible in DEV_ 
BStZE [currently 1024 bytes] units. Unfortunately, the 
minimum size of an accessible CD-ROM disk I) lock is 2048 
bytes | ;a multiple of DEV.BStZEj according to the CD-ROM 
standard, For read requests to a CD-ROM ♦ care is taken in 
the CD-ROM file system < ode to ensure that reads Start On 
2048-byte boundaries with sizes in multiples of 2 04 8-byte 
blocks. 

Smaller Logical Blocks. The logical block size of a CD-ROM 
can be 512, 1024, or 2048 bytes as determined by the data 
preparer. If the size of a logical block is less than 2i)4H 
bytes, the whole 2048-byte disk block containing the logical 
block must be read from the disk. However, only the logical 
block is copied into the user's buffer. 
Interleaving. To optimize access time and to match an 
application's expected access patterns, files on a CD-ROM 
file system can be recorded in interleaved mode for each 
file, and the size of a file unit and a file unit gap can be 
random as long as the sizes are multiples of 2048-byte 
sectors. A kernel routine, cdfs_rd. was implemented to use 
information in the cdnode such as file location, extended 
attribute record size, file unit size, and file gap sixr 1<j 
calculate the location of each section of a file, If necessary, 
cdfs.rd also con catenates pieces of data from different file 
sections into blocks before passing the file back to callers. 
This routine also tries to maintain the size of a buffer to 
8K bytes whenever appropriate so that buffer management 
efficiency can be maintained. 

Demand-paged exec. One major challenge was to support 
direct execution of demand- paged programs on a CD-ROM. 
In the current implementation of HP-UX, virtual memory 
depends on files being physically divided into fixed-size 
blocks (minimum of 4096 bytes for HP 9000 Series 300 
computers), except for the last block. The disk address for 
each block is kept in the system page table when the files 
are first executed via the exec call, When a file is paged in, 
the file's disk address is used to read in the block by calling 
the relevant device strategy routine directly. Since the files 
on a CD-ROM can be recorded in interleaved mode and 
the size of file units can be any number of logical blocks, 
w T e cannot rely on the page-in routine to read in pages from 
the disk directly by calling the device strategy routine. For 
CD-ROM files, instead of the file's physical disk address, 
the offset into the file is stored in the page table. With this 
setup, when the file is paged in. a routine called cdfs_strategy 
uses the file offset to read in the page by calling the cdsf_rd 
rent inc. The cdfs_rd routine hides the fact that the portion 
of the file containing the page may not be contiguous on 
the disk. 

Diskless Protocol. HP-UX supports diskless clusters, and 
a client's requests are passed via a lightweight protocol to 
the server. This protocol assumes there is only one kind 
of file system. A switch was added to this protocol to accept 
different kinds of file svstems. 



Testing and Validation 

To ensure Compliance with our design goals, the follow- 
ing methods were used to test and validate the CD-ROM 
file system implementation. 

Commercial CD-ROMs. Several commercially available 
CD-ROMs were purchased to see if they could be accessed 
through the CD-ROM file system. In selecting the CD-ROMs 
lo purchase, first the mastering companies used to produce 
the disks were chosen and then at least one CD-ROM was 
pun based from each. By doing this, the CD-ROM file sys- 
tem code was exposed to different interpretations of the 
standard. 

Regression Testing. The HP-UX kernel is subjected to 
nightly regress ion and veriiit uhuit (est nig by an automated 
test suite. Tests were added to this suite that mounted a 
CD-ROM file system volume and verified proper system 
call behavior. System calls were tested on stand-alone and 
diskless configurations. 

Test Disk, A test CD-ROM was produced that contained 
many items (lot available on commercial CD-ROMs. This 
test disk contained several releases of I JP-UX (to investigate 
the possibility of software distribution on CD-ROM), 
executable programs from HP 9000 Series 300 and Series 
800 computers (in particular, to test demand-loadable 
executables] , huge files, small files, uncommon filenames, 
and so on. The test disk was particularly useful in testing 
the demand-loadable executables, but because the CD-ROM 
manufacturers could not create some of the more exotic 
data constructs (such as extended attribute records and 
interleaved files), testing of these constructs w r as not possi- 
ble. 

Cdgen. Because there are many possible data constructs 
that are not widely used in the industry today, such as 
interleaving, multisection files, associated files, and ex- 
tended attribute records, there was no way to test the paths 
in the CD-ROM file system code that handles these cases. 
To solve this, a CD-ROM image generator called cdgen was 
written to create a simulation of a CD-ROM. Cdgen takes a 
list of files and creates a CD-ROM image from them. This 
image is then written to either an HP-UX file or a hard 
disk. The hard disk can then be mounted and treated as a 
CD-ROM file system volume. Cdgen supports the following 
standard data formats and constructs: 
m HSG or ISO 9630 format 

■ Multiple directory hierarchies per volume (primary and 
supplementary volume descriptors] 

■ Multiple volume descriptor set terminators 
m Interleaving 

■ Extended attribute records 

■ Multisection files 

■ Associated files 

■ System use, system area, application use, and escape 
sequence data in all constructs that provide them. 

Cdgen was first used to test obscure corner cases such as 
interleaved demand-loadable executables, directories end- 
ing exactly on a sector boundary, zero- length files, and 
system use data in "." and *\." directory records, Later, 
automated tests were written that incorporated cdgen. and 
the tests were added to the kernel regression test suite. 
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Conclusion 

All of our design goals were achieved and the delivered 
performance matches the speed of the underlying device. 
The structured design techniques used during design made 
some sections of the CD-ROM file system code very mod- 
ular. Pathname lookup is much simpler and more modular 
than its counterpart in HKS, even though the CD-ROM file 
system directory structures are more complicated. Al- 
though the I/O rate is very dependent on the physical layout 
of the data on a CD-ROM it was measured at 149.9 kbytes/'s 
(the maximum for a CD-ROM drive is 150 kbytes s] without 
the help of the buffer cache. All nontilp-syM^m-dependent 
commands and CD-ROM applications from independent 
software vendors that we tested ran without changes. The 
quality of this system improved after the last few corner 
case errors were identified by the images created with cdgen. 
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favorite pastimes include skiing, tennis, and 
boa rdsai ling. 
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of California at Berkeley 
His research determined which materials are best 
suited tor use in network and signal analyzers 
Presently, he is developing a proprietary manufac- 
turing process to be used in the latest HP input de- 
vices. Nguyen joined HP's Network Measurements 
Division in 1979 He is a member ol the American 
Society for Metals and has contributed articles to 
Experimental Mechanics, Machine Design, and 
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X.25 Packet Assembler/Disassembler 
Support in the HP 3000 Data 
Communications and Terminal Controller 

The PAD support software implements the communications 
protocols specified in CCITT recommendations X.3 and 
X.29. For performance reasons, the software is in the 
datacom and terminal controller (DTC) rather than the host 
MPE XL system. 

by Jean-Pierre Allegre and Marie-Therese Sarrasin 



FIRST RELEASED IN 198fi. the HP 2345 A distributed 
terminal controller (DTC), 1 offered connectivity 
from personal computers, terminals, and printers 
(o a single HP 3000 computer system running the MPE XL 
operating system. The DTC, connected to the host comp liter 
by an IEEE H02.3 local area network (LAN), could be 
thought of as a remote multiplexer. 

From a hardware point of view, the DTC is built around 
an HP proprietary bus called the Device I/O (DIO) bus. A 
server card with a 68000 micro processor handles LAN ac- 
cess and DIO management. Up to six multiplexer cards 
with Z80 microprocessors can be plugged into the back- 
plane. Adapter cards give each multiplexer card either eight 
direct-connect or six modem ports. Thus the first version 
of the DTC allowed up to 48 direct connections to an MPE 
XL system (see Fig. 1). 

From a software point of view, the DTC uses its own 



minimal operating system, called AOS. AOS is a message- 
based operating system that manages intertask communica- 
tion. Each software module is a task in operating system 
terms. A task interacts with the other tasks by sending 
messages. The operating system manages a queue of mes- 
sages. When a message is at the head of the queue, it is 
dequeued and given to the target task. Then the target task 
executes and is not interrupted until the message is com- 
pletely processed. Hardware interrupts are managed by 
operating system handlers lhat transform these interrupts 
into operating system messages, 

On top of the IEEE 802.3 LAM. the DTC implements an 
HP proprietary protocol. AFCP, for the transport layer of 
the seven-layer Open Systems Interconnection (OS1) model 
of the International Organization for Standardization (ISO). 
This transport protocol is optimised for LAN traffic and 
its peer is implemented in the host computer system. The 
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Fig. 1 . The original HP 2345A dis- 
tributed terminal controller could 
be thought of as a remote multi- 
plexer 
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transport layer carries terminal I/O requests that are en- 
coded using another proprietary protocol, ADCP, which 
manages nil [he terminal read, write, and control functions, 
it has alsu been optimized lor performance. 

The sell ware architecture of the original DTC is shown 
in Fig, 2* The management task [MGT in Fig. 2) handles 
all the management requests within the DTC along with 
initialization. Among its important functions arc software 
download and upload. At initialization* the DTC sends a 
multicast request. Upon receiving this request, the host 
starts sending the DTC code through the LAN, This allows 
easy updates of the code without the need for a ROM 
change. When the DTC detects an abnormal condition, it 
is able to upload its entire memory to the hast, allowing 
further study by an HP representative for troubleshooting. 
The management task also handles all the reset and status 
requests. 

The DIODAM task is in charge of managing the UIO bus 
interface and also does some ADCP preprocessing. 

The MUX task transforms the read, write, and control 
requests into characters transmitted to each terminal. It 
also multiplexes several independent data streams to the 
backplane slots. 



Second DTC Release 

In its second major release, the HP 2345A has been re- 
named the data communications and terminal controller. 
It now offers the following new functionalities (see Fig. 3); 

■ PC-based management 2 

■ Access to X.25 packet-switched networks through syn- 
chronous network processor (SNP) cards 

■ A capability for terminals to switch from one MPE XL 
host to another on the LAN 

■ Back-to-back access to non-MPE XL systems connected 



IEEE B02.3 LAN 



DIODAM (ADCP) 




Fig, 2. Software architecture of the original DTC. AOS is the 
operating system, AFCP and ADCP are proprietary protocols. 

via RS-232-C to another terminal controller [DTC orTSS) 

on the LAN. 

The X.25 access provides for system-to-system communi- 
cations as w r ell as for remote terminal communications. Up 
to three SNP cards 1 which are based on the 68010 micropro- 
cessor, can be plugged into the DIO backplane instead of 
multiplexer cards. SNP adapters of two different kinds 
allow high-speed, multistandard or RS-232 SNP connec- 
tions to the X.25 network. Bach SNP card can handle up 
to 256 connections for X.25 packet sizes of 128 t 256 t or 
512 bytes and up to 54 connections for a packet size of 
4096 bytes. Access to the LAN is through the server card, 
as it was in the original DTC. 

The second- re lease DTC is managed through a personal 
computer using the HP OpenView DTC Manager," an appli- 
cation based on Microsoft" Window's and the HP OpenView 

Microsoft is a US. registered trademark ol Microsoft Corporator! 
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Fig, 3. The second-release HP 
2345 A DTC, renamed the data 
communications and terminal con- 
troller, offers X.25 network access, 
the ability of terminals to switch 
from one host to another, and 
back-to-back access to MPE V 
systems on the LAN 
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network management architecture. The management fea- 
tures include; 

■ DTC configuration 

■ DTC download/upload reset status 

■ Board upload reset status 

■ Site management (show connections with information 
on end-to-end path) 

■ Protocol status 

■ Connection upload reset f status 

■ Logging and tracing. 

The same operating system runs on the server card and 
on the SNP cards. From the operating system point of \ 
the server card is the master card and each SNP card is a 
slave card. Communication between tasks feom the server 
board to an SNP board over the DIO bus is managed by the 
operating system. A message can be sent to any task from 
the master board to the slave board and vice versa in a 
transparent way thanks to the operating system's mul- 
tiboard communication mechanism. Messages from the 
server to the SNP are copied by the operating system onto 
the SNP board. Messages from an SNP task to the server 
don't need to be copied because the server board can access 
all of the SNP cards' memory* 

To make these functionalities possible, many protocols 
have been added in the DTC. Fig. 4 shows the possible 
paths through the DTC and its protocols. 

ALCP is an HP proprietary protocol based on the CCITT 
X.213 recommendation. An OS! Network Layer Service for 
Connection-Oriented Protocols, ALCP offers X.25 access 
far host-to-host communications. Two operating syslem 
tasks, X.25 Level III and X.25 Level 11, implement ALCP, 
the X.25 level III recommendation, LAP-B [X.25 level II), 
and X.21 bis (X.25 level I), X,25 data is encoded in ALCP 
messages and transmitted to the host using the AFCP trans- 
port layer [level IV) and vice versa. 



The term in aJ switching capability is offered by DTC user 
interface commands located in the DIODAM task. 

The back-to-back functionality is offered with the im- 
plementation of the Telnet TCP IF stack. Telnet is a DARPA 
standard network virtual terminal protocol and is im- 
plemented in the DIODAM task. ADCP (the HP virtual ter- 
minal protocol) has been enhanced to support ihe added 
Telnet functionality. The TCP and IP protocols have been 
implemented as two independent DTC tasks on the server 
board. 

Communication through remote asynchronous PAD de- 
vices is implemented in a PAD support task [PADSUP] on 
the SNP board. 

The DTCMGR agent task replaces the management task 
of the first-release DTC. This task receives terminal and PC 
requests and transmits them to the appropriate DTC task. 

The target name resolution task (TNR in Fig. 4) is in 
charge of name-to-addrcss resolution using configuration 
information. HP proprietary protocols [Probe or Name 
Lookup Protocol, NLP), or standard protocols (Address Res- 
olution Protocol, ARP). 

The DTCMGR extension (EXT) task provides the SNP 
logging and tracing facilities. These functionalities send 
data to the personal computer running the HP OpenView 
DTC Manager software, which is able to format and display 
the data. 

PAD Support Functionality 

A PAD (packet assembler disassembler) is a piece of soft- 
ware attd/or hardware that allows an asynchronous device, 
such as a terminal or a printer, to communicate with an 
X.25 network. PAD support in the DTC provides a host 
computer with support for terminals connected to public 
PADs (also called network PADs] and with support for 
terminals and printers connected to private PADs. 



System-to-System Path 



Local Device-lo- 
PAO'to-Host Path Host Path 



Back-to-Back 
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Fig. 4. Software architecture of 
the second-release DTC. X.25 ac- 
cess is through SNP cards m the 
DTC The PAD support software 
is on the SNP card. TNR f$ m 
target name resolution task. Tel- 
net, TCP, and IP are standard pro- 
tocols. AFCP and ADCP are pro- 
prietary protocols The path 
through the protocols depends on 
the type of connection 
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Communication between a PAD and an asynchronous 
terminal is described in the CCITT X.28 recommendation. 
The different parameters necessary to set up the proper 
terminal profile are defined in the CCITT X.3 recommenda- 
tion, and communication between the host and the PAD 
is ruled by the CCITT X/23 recommendation (see Fig. 5). 

A private PAD can be thought of as an external PAD. It 
is connected to a PDN (public: data network) as a host and 
has an X.25 address, but it behaves like a PAD when com- 
municating with another host. HP provides the HP 2334A 
and HP 2335A X,25 cluster controllers, which allow up to 
16 terminals and for printers to access a network (see Fig. 6). 

Applicable Standards 

The CCITT has issued X.25, X.28, X.29, and X.3 recom- 
mendations in 1976, 1980, 1984, and 1988, 

The objective of MPE XL PAD supporl in the second- 
release DTC is to Support applications by using the X.3 
and X.29 recommendations and philosophy, To achieve 
this, the PAD support must manage the X.3 parameters in 
such a way that the user does not have to care about them. 
In the new DTC, the same processing is done for every type 
of PAD — public or private. The PAD support sets parameter 
values according to the 1980 X.3 recommendation so that 
the DTC can support as many PADs as possible. 

The PAD support in the new DTC uses X.3 and X.29 to 
transmit control requests to the PAD. The X.3 recommen- 
dation defines a set of couples of parameter references and 
values to control the asynchronous interlace of the PAD. 
According to the 1980 X.3 recommendation, eighteen pa- 
rameters are available to manage a PAD: 



1 Escape from data transfer and enter a PAD command 

2 Echo 

3 D ata f o rward i ng co nd ition 

4 Id te ti mo r (ti me between two characters) 
5.12 Flow control using XQN.XOFF 

6 PAD service signals 

7 Break processing 

8 Discard output 

9 f 10 ; 1 4 Padding after CR, LF, LF line folding 

11 Line speed 

1 3 Linefeed insertion after CR 

15.16.17,18 Editing parameters. 

A simple example is the parameter reference 2, defined 
for echo processing. If this parameter is set to the value 
the PAD will not echo the data sent to the network. When 
the value is set to 1 the PAD is in charge of echoing the 
data entered on the terminal keyboard to the screen. There- 
fore, a reference number specifies a functionality (e>g> t echo 
processing] and many values can be attached to this func- 
tionality (do echo, do not echo]. 

In the 1984 X.3 recommendation, four more parameters 
were added along with the possibility of having network 
dependent formats for PAD devices. The four added param- 
eters are: 

1 9 Editing PAD service signals 

20 Echo mask 

21 Parity treatment 

22 Page wait. 

In the 198H X.3 recommendation, the main modification 
is that PAD service signals (prompts and user messages) 
can be in English, French, or Spanish. 

To transmit the X.3 parameters to the PAD, the X.29 
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Fig. 5. Connection through a 
public or network PAD, showing 
the CCITT recommendations that 
govern communications. 
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recommendation is used. This recommendation defines the 
operations a host can perform on a PAD. According to the 
1980 X.29 recommendation, the main operations on a PAD 



are: 

Set 

Read 

Set and read 

Parameter indication 

Indication of break 



Invitation to clear 
PAD error message 



Set a profile of X.3 parameters 
Reouest trie PAD X,3 parameter values 
Set a profile and then read it 
Receive the values of the required current 
PAD profile after a read or set and read 
Notify the host that the Break Key has been 
pressed and tell the host whether the PAD 
is discarding data 

Clear a virtual circuit as soon as all data sent 
to the PAD has been sent to the device 
Indicate a PAD problem (invalid message 
code received, for example) 



A profile is a set of X.3 parameter references and values- 
All these messages arc coded and transmitted using X,25 
packets with the qualifier flag set, The usual convention 
fnr describing a profile is 

[< parameter reference> : < parameter value>.]* 

For example, 2:1 , 3:2, 4:1 means thai parameter 2 has value 
1, parameter 3 has value 2, and parameter 4 has value 1, 
In I he 1984 X>29 recommendation, a new message was 
added, called the reselectinn PAD message. It makes it 
possible to clear an X<25 circuit to a destination after trans- 
mission of all the data and to establish a new circuit to a 
given destination in the same message. In the 1988 X.29 
recommendation, this was enhanced to support iheTOA/ 
NPT (type of address/numbering plan indicator) address 
subscription facility defined in the X.2 recommendation, 
Th is enhancement is mainly for future extension to ISDN. 



DTC PAD Support Architecture 

We could have built a PAD support task in the host 
computer on top of the NetlPC [network interprocess com- 
munication) software using the VT (virtual terminal) net- 
work service. This was done for MPE V PAD support. For 
the DTC and MPE XL. we have instead built a task called 
PADSUP within the DTC, mainly for performance reasons. 
This decreases the amount of character processing that 
must be done by the host, since this is done remotely by 
the PADSUP task in the DTC front end. All X.3 and X.29 
processing is in the DTC PADSUP task, so the entire X.25, 
X.3. and X,29 implementation is within the DTC, 

The PADSUP task receives ADCP requests from the 
DJODAM task as if it were a multiplexer with a physically 
attached terminal. It transforms these requests into X.25 
and X.29 requests through the ALCP interface. 

This architecture has many advantages. Remote termi- 
nals have the same data path in the host as local terminals, 
thereb\ r decreasing the lime needed for implementation, 
support, and maintenance. The known ADCP protocol, 
which was designed for the original DTC, was retained 
because it is simple and efficient for asynchronous com- 
munications, and very few extensions were needed for PAD 
devices. The ALCP interface, which is already used for 
system-to-system communication, is used to communicate 
with the X,25 level III module. The efficient, reliable AFCP 
transport protocol is used for communication with the MPE 
XL host, and access to the transport layer is hidden by 
DIODAM 

The architecture also allows switching capability. Be- 
cause the user interface is in the DIODAM task, ihe I Na- 
tionality implemented for the local terminals can be reused 
by the PAD support task to connect remote terminals to 
any MPE XL computer cm the LAN. 
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Fig. 6. Connection through a pri- 
vate PAD such as the HP 2335A. 
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Security 

Through the X.25 network and gateways, numerous PAD 
users may try to connect to various systems. This causes 
security concerns for system and network managers, who 
need to restrict the use of some systems. For example, when 
private X.25 networks are tied In public networks, access 
is often authorized for users within the private networks 
and restricted for public PAD users. On the other hand, 
some custtjmers don't care about security. To meet varied 
customer needs, the DTC PAD support offers flexible se- 
curity features. 

Two kinds of security are provided. First, a management 
function available from the HP OpenView DTG Manager 
PC workstation can be used to start or stop the PADS UP 
task. When the PADSUP task is not started on a card, all 
PAD calls will be cleared. 

The second type of security is a security list based on 
the X.25 calling address, Users with unauthorized X.25 
device addresses are filtered oul at (he DTC level. A table, 
configured at the HP OpenView DTC Manager PC, as- 
sociates X,25 device addresses with host names and pass- 
words. When the user tries to log on with security con- 
figured, the password tied to the list must be entered in 
the user data of the call packet or through the DTC user 
interface. The user is allowed three attempts to enter the 
password, If a wrong password is entered or if the node 
name to which the user wants to be connected is unau- 
thorized! the connection will be cleared. Users who know 
the password can be allowed access to all systems or only 
to certain systems. It is also possible to reject all users 
calling from a particular address. Wildcard digits are avail- 
able for use with public PADs. where the X.25 address is 
not relevant. 

Testing the PAD 

A major problem for FAD support is managing multiven- 
dor PADs connected to multi vendor devices. The X.3 re- 
commendation defines a set of parameter values that look 
like driver characteristics. There have now been four suc- 
cessive editions of this recommendation from the CCITT, 
Each PAD vendor implements only a subset of the latest 
X.3 parameter values. From experience, we know that even 
some mandatory values aren't implemented in some PADs. 
It is always a support nightmare to characterize a PAD 
problem, especially if the problem is that the system is 
hung up in the middle of an application. 

To alleviate this problem, a PAD test sequence is im- 
plemented in the DTC. It is run at connection initialization 
to verify the X.3 parameter values supported by the PAD. 
After this test, information is available to inform the net- 
work administrator of potential intrinsic mappings that 
may fail because of PAD restrictions. Once data transfer 
starts, the PADS UP task always knows what it can and 
cannot ask the PAD to do. 

To map all the intrinsics used in the terminal I/O world, 
only a subset of the X.3 couples (parameters and values) 
is needed, PAD support in the DTC tries to set all the values 
at connection initialization that will be needed during the 
connection to support all the applications. If a parameter 
is not supported by a PAD. an error is logged and the DTC 
PAD support never sets this parameter again, thereby avoid- 



ing further problems. This implementation exposes all the 
multi vendor PAD problems at connection initialization, 
which seems the best point 1o detect problems, 

The PAD test is performed by the PAD support task just 
after the X.25 call confirmation packet is received by the 
DTC from the host (host calling terminal ] or sen! by the 
DTC to the host (terminal calling host). The sequence is as 
follows: 

1, Identification of PAD parameters. An X.29 read of all 
PAD parameters is sent to identify the parameter numbers 
supported or not supported by the calling or called PAD. 

2, PAD test. An X.29 set and read of a given set of X.3 
couples is sent to the PAD. These couples consist of the 
parameter numbers supported by the PAD with the param- 
eter values required by all types of applications. To 
minim ize the number of messages needed to determine the 
characleristics of the PAD H the first X.29 set and read mes- 
sage sets alls the values that may be used for each param- 
eter. For example, the profile of couples might be 1:0,1:1, 
2:0,2:1,3:0.3:2,4:0,4:1,4:10, and so on. 

The PAD support task then waits for an X.29 parameter 
indication, in which all unsupported parameter values are 
marked by an error flag. When such a value is detected, 
an event is logged if the value is considered optional (for 
example, if parameter 4 is not supported, HP VPLLIS appli- 
cations can't work with this PAD), or the connection is 
cleared if the value is considered mandatory (for example, 
parameter 5 with the value 1, PAD flow control]. Some 
PADs don't follow the 1980 X.29 recommendation and an- 
swer with X.29 PAD error messages for the values they 
don't support. In this case, many set and read messages 
are sent to identify the unsupported couples. 

At the end of this sequence, a list of supported PAD 
parameter values is computed and stored for later use in 
data transfer. 

3, PAD configuration. An X.29 set of all the parameters is 
sent to initialize the PAD profile. 

Mapping ADCP Requests 

The PADSLJP task must transform ADCP requests into 
X>25'°X,29 data, and is in charge of user data editing. Only 
the main path is described here. 

To establish a connection to a host MPE XL system from 
a remote terminal, the user enters the X.25 address of the 
desired DTC or host. The PAD transmits an X.25 call to 
the DTC, which decodes the X,25 host address and trans- 
lates it into a host name usin u H configuration data. With 
this host name, the DTC can send a request onto the LAN 
using the HP Probe protocol to retrieve the LAN address 
of the MPE XL host system. With the LAN address, the 
connection can be initialized to the host. 

Upon a host request to establish a connection to a PAD 
port, the DTC receives a string that identifies the device. 
Associated with this string is an X.25 address obtained 
from configuration data. With this X.25 address, an X*25 
call packet can be transmitted to the PAD. 

Write data is transmitted to the PAD as X.25 data. For a 
write and read operation, the PADSUP task sends data to 
the device and expects data from the device. When data 
comes from the device, the PADSUP task is in charge of 
data editing [suppression of backspace, detection of subsys- 
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tern break). The read data is sent to the host as soon as a 
read termination condition is encountered by the PADS UP 
task (end of record detected, byte count reached, time-out, 
titc.)- 

Control requests correspond to setting driver parameters. 
They are mapped into X.3 couples by the PADS UP task 
and are sent \0 the PAD- The list of supported parameter 
values, built during the PAD test, is used to ensure that 
the PAD is sent only the couples it is able to use. For 
example, when an HP VPLUS block mode application is 
used, the PADSUP task receives a write port i onfiguration 
command with a flag indicating thai the HP VPLUS block 
mode is enabled. The task then configures the PAD with 
the X.3 parameter values corresponding to no escape from 
data transfer [1:0), no echo (2:0) T data forwarding condition 
(3:0,4:10), break enabled [7:21). XONXOFF flow control en- 
abled (5:1,12:1), no editing (15:0). When the user presses 
the Enter key, all of the data on the current screen is sent 
by the terminal to the FAD T which sends it on to the DTC 
PAD support task because of the data forwarding condition. 
All full packets are sent to the DTC and the last packet is 
sent using the idle timer value specified by parameter refer- 
ence 4 set to the value 10. 

Another example is the transmission of a break to the 
application. If the application authorizes the user to press 
the Break key, the PADSUP I ask receives a control request 
consisting of a write port configuration message with a 
break enabled flag. The task sends an X.29 set to the PAD 
to enable break processing (7:21). When the user presses 
the Break key to interrupt processing, the PAD sends an 
X.25 interrupt packet to the DTC PADSUP task along with 
an X.29 indication of break packet, The PAD will discard 
all data received from the DTC- On the X,25 interrupt, the 
PADSUP task sends an asynchronous break detected event 
to the DIODAM task, which transmits it to the host. On 
the X.29 indication of break, the PADSUP task sends an 
X.29 set to the PAD to reset the PAD discard output state 
(set 8:0). This message flushes all data buffered in the X.25 
network and puts the PAD in a normal delivery state. New 
data coming from the application can again be displayed 
on the terminal. 

In the case of a control request to clear a connection, the 
PADSUP task receives in AFCP abort connection message 
from the DIODAM task to shot down the X.25 connection, 
Special care must be taken wheo it comes to closing a 
connection, X,25 clear packets are not flow controlled as 
X.2 5 data packets are. sn it ts possible that the clear packet 
may overtake the last data packet sent and therefore the 
last data for the PAD device may be lost. For this reason, 
X,29 specifies a safe way to close a connection. The PAD- 
SUP task does not send the X.25 clear packet, hot instead 
sends an X.29 invitation to clear message, which is flow 
controlled Like normal data. When the PAD receives this 
message, it will already have received all the X,25 data, 
and will then issue an X.25 clear message, On receipt of 
the X.25 clear message, the PADSUP task can clear its in- 
ternal table. 

When the connection is cleared by the user PAD (with 
the X.28 CLR command, for example], the PADSUP task 
sends an ADCP asynchronous link level disconnected mes- 
sage to the DIODAM task, which transmits it to the host, 



closing the AFCP connection. 

Editing 

One of the functions performed at the PADSUP level is 
data editing. This consists of processing the byte stream 
received from the X.25 network and delecting any special 
characters for which actio be performed. These 

special characters include backspace, line delete, su 
tero break, and others. They are configurable ASCII values 
that the application sets using file system intrinsics such 
as FCONTROL The PADSUP task has to be able to process 
these characters according to their configured ASCII values. 
Usually, part of the processing is done by the PADs. most 
of which are able to process backspace and line delete 
characters, However, because ADCP provides more editing 
features than X,3. and because all PADs don't support the 
editing functionality, the PADSUP task has to be capable 
of doing this processing itself. 

Editing is on the critical code path, It is invoked for any 
inbound X.25 packet and requires character-by-character 
processing. The more straightforward algorithm is to use 
a cascade of IF statements, Because there are eleven special 
characters to test for, this makes eleven tests for each 
character. The most frequent case, a normal character, is 
the worst case because all eleven tests must be performed 
before il is known that there is nothing to do. On the other 
hand, this algorithm consumes very little memory because 
it requires storing only the eleven special values. Each 
connection can have a different set of values configured 1 
so the total number of values that must be stored is 11 x 256, 
where 256 is the maximum number of connections, 

The algorithm we have implemented is more memory- 
consuming but has much better performance. The main 
principle is to use a structure that we call a character filter. 
It is an array of 2 SB entries for each connection [256x256 
total entries), indexed by the ASCII values. Kach entry rep- 
resents a particular action to perform, For example, if the 
backspace character is represented by the ASCII value 08 1 
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Fig. 7, A write port configuration message results in the build- 
ing of the character filter. 
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at the index OB ihe PAllSUP task records the code for the 
backspace action. The most frequent action is no action for 
the normal characters and is coded with 0. The array is 
initialized to zero and the proper actions are recorded at 
the ASCII values of the special characters when a special 
ADCP control message called a write port configuration 
message is received from the host fsee Fig, 7], 

When the data arrives from I he X.25 network, the editing 
algorithm is executed (see Fig. 8). For each character, the 
action to be performed is fetched from the character filter 
and executed. In the case of a normal character, nothing 
is done. For the others, the appropriate processing is 
triggered. 

To avoid a test of the length of the buffer i<n each charac- 
ter, a special character called the end of data marker is 
written at the end of the buffer. A special action is recorded 
in the character filter lor this character. When this character 
is encountered, this action is triggered, and only in this 
case is the test of the length of the buffer made. If the end 
of the buffer has not been reached, it means that the end 
of data marker was part of the user data and should be 
treated as a normal character, so no action is taken. 



specifications. We organized, ranked, and ordered the 
characteristics to meet the requirements. We chose to fol- 
low the structured analysis with a structured design, pro- 
viding three kinds of documents; structure chart, module 
specifications, and design dictionary. The structure chart 
shows the basic components of the solution and shows I he 
interfaces in a top-down manner. The module specifica- 
tions define the procedural aspects of the solution, or the 
sequence of interactions. The design dictionary defines the 
interlaces. 

A first review of the main module organization was done 
to verify the encapsulation, design cohesion, and coupling 
of the differenl modules. The main modules were then 
designed independently. 

A complete review of each module was done to find the 
design flaws. This was highly successful because we found 
all the complex areas before coding and were able to re- 
design the parts that were too complex. As a result, very 
few design bugs were found tin ring testing, 

In the coding phase, the design documents helped us to 
he productive rapidly. The code was done in C on HP-UX 
workstations. 



PADSUP Development Methodology 

In developing the PAD support component, the first step 
was to define the external specifications of the product. 
All MPK XL intrinsics and the X.3 and X.29 recommenda- 
tions were analyzed to define what could be supported and 
what could not be supported because of X.3 recommenda- 
tion restrictions. The configuration r md I he support fea- 
tures were studied with the participation of HP marketing 
people. 

The second step was to define the best architecture to 
provide the desired functionality, We analyzed the data 
How rrom the host to the DTC and the PAD, and then 
defined the component responsibilities for the host mod- 
ules and the DTC modules, 

The third step was to analyze the exact characteristics 
of the PADSUP task within I he DTC. For this, we used the 
structured analysis method" 1 4 with the HP Teamwork SA/ 
RT tool to define what needed to be done without regard 
lo how it would be done. We then drew a functional model 
(what the system does], a data model (how data is trans- 
formed), and a behavior model (state transition diagram 
and matrix, and decision tables that characterize the sys- 
tem). This method was of considerable benefit for analyzing 
and detailing all the mechanisms needed in the PADSUP 
task. The graphic representation and the top-down method 
helped us better locate where the complexity and the main 
incidence of all the features occurred on the model. A 
review was done to verify the PADSUP analysis. This 
analysis gave us some metrics (Bang,* estimated number 
of decisions or branches, etc.) to characterize the module's 
complexity, helped us in schedule estimation, and gave a 
good idea of the tests needed during the qualification phase. 
During this phase, the project model and the preliminary' 
test plan were completed. 

PADSUP Task Design 

During the PADSUP task design phase, we defined what 
modules and what interfaces were needed to meet the 



PADSUP Task Testing 

The PAD support task has been tested in a multiple-step 
process. The large! code (to be downloaded to the hardware 
later) was produced with the HP-UX C compiler on an HP 
9000 Series 300 workstation and then postprocessed. This 
was possible because the microprocessor on the SNP card 
is a 68010. which is of the same family as the workstation 
microprocessor. This made it possible to test the code in 
a comfortable environment (diskless workstation] and then 
port the code to the hardware with a high level of confi- 
dence, since the target code was almost the same. One of 
the main advantages of doing this was the availablity on 
the workstation of many C tools that we could use on the 
target code (C debugger, branch flow analyzer, prof for per- 
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formance analysis, etc.). 

The multistep testing process consisted of unit testing, 
integration testing* and real-environ men! testing. Related 
issues include testing in the maintenance phase and testing 
of mill ti vend or PADs. 

Unit Testing, The objective of this step was to bring each 
individual component (procedure or function) to a good 
quality level for later integration. The designer of each 
procedure or function was responsible for developing code 
stubs to exercise the component, This was done at the unit 
level, that is* the component was tested by itself and not 
in a complete environment. This level of testing exposed 
most of the coding errors. 

Functional Testing. At this test level, all the individual 
modules of the PADSUP task were merged together and 
exercised in a functional way, that is. we were testing 
whether the module was indeed performing the functions 
specified. This was mainly achieved with the message 
machine described in the article on page 74. which is capa- 
ble of building messages, sending them to the module under 
test, receiving the output, and decompiling it in a readable 
format . In regression mode, output files were compared to 
reference files that had been manually checked during pre- 
vious testing. Since both the output file and the reference 
file were in readable forma!. I fie differences were easy to 
see. All of these tests were run on the HP-UX workstation. 

The message machine tool was really convenient to use* 
With it T wo easily achieved the branch flow analysis (BKA| 
coverage required, The objective of the project was to test 
85% of all the software branches. We have achieved 
without the need of any additional operations such as set- 
ting breakpoints or adding code, Moreover, because the 
tool provides for easy automation, all of the test suite has 
been maintained and now we can run a regression test 
overnight without any external intervention and reach a 
BFA coverage of 93% on each version or patch released. 
The number of test cases is quite large. Up to 50,000 differ- 
ent messages are sent to the module under test, and the 
overall size of all the output files that are checked for dif- 



ferences with reference files is 36 megabytes. 
Integration Testing. These tests were conducted at two 
different leveb: in the simulated environment provided by 
the message machine under the HP-UX operating system 
and in the target environment (hardware). 

The objective of the HP-UX integration testing was to 
add step-by-step all of the tasks external to the PADSUP 
task in the simulated environment- hi the tirst step, all of 
the other tasks were emulated by the message machine. 
These were then replaced, one by one, with the actual 
tasks, and the system was exercised by the message 
machine. Finally, all of the interfaces with other modules 
were tested and debugged with the actual tasks still on the 
workstation, 

For hardware integration, the code was downloaded to 
the hardware and run in its final environment. Because of 
the multiple tests already conducted, the quality at this 
stage was already rather high and we found very few defects 
during this testing. The principal tool we used was a debug 
port that allowed us to connect a terminal to the board and 
set breakpoints, dump memory areas, and so on. 
Real-Environment Testing. These tests were done mainly 
by the QA department to test the quality objectives of the 
product in the areas of functionality, localizability. usabil- 
ity, reliability, performance, and serviceability. The setup 
used was close to a real customer environment, For ease 
of testing, two different environments have been used: a 
real PAD environment and the XXPAD environment. 

The real PAD environment is a customer-type environ- 
ment. It consists of an MPE XL system, a DTC with SNP 
cards, an XJ25 network or switch, PADs, terminals, and 
printers. The tests consist mainly of manual validation (for 
DTCMCR functions, lor example] and of test programs run 
on the MPE XL system that exercise the datacom functions 
through the system Intrinsic s. The problem with this Setup 
is that the number of sessions is limited by the hardware. 
The DTC supports 256 PAD connections per synchronous 
card and three synchronous cards per DTC, so a full test 
requires so much hardware that it is impractical, Tuapprnx- 



HP 3000 MPE XL 
System 




HP OpenVJew 

DTC Managar 

PC 



PAD traffic 

generated programmaticaly 

from the script file, 



Up to 360 PAD connftctiont caw 
be simulated on I ha Wnm, \ 



J 



NSX.25 
Level 3-2-1 



i MPE V 
System 



Fig. 9, The XXPAD too! was de- 
veloped to test the PAD support 
software in the DTC without exces- 
sive hardware The too! can simu- 
late multiple connections The first 
versions ran on an MPE V system 



DECEMBER 1SS0 HEWLETT-PACKARD JOURNAI 71 



)Copr. 1949-1998 Hewlett-Packard Co. 



imate a full test (Le. r limit, stress, and volume testing), we 
use the XXPAD environment. 

The XXPAD environment makes it possible to minimize 
hardware setup. The PAD is basically a multiplexer of many 
asynchronous lines (16 in the case of the HP 2335A PAD) 
to a single X.25 line. Therefore, instead of managing 16 or 
more terminals, we can jusi pul on the X.25 line a piece 
of hardware and software that emulates numerous asyn- 
chronous devices. This way, the number of connections 
tested can be increased simply by increasing the number 
of virtual circuits handled by the test machine. For ease oi 
implementation and for hardware availability, this tool was 
developed on an MPE machine running HP NS X.25 soft- 
ware, which provides programmatic access to X.25 level 
III. On top of the level 111 access p we developed a lest pro- 
gram called XXPAD, which is able to handle as many vir- 
tual circuits as required. This program reads the instruc- 
tions to execute (basically user commands] from a script 
file and handles both X.25 and X.29 data. 

For the PADS UP tests, the scripts simulated multiple 
users connected to the DTC and to the MPK XL system and 
running some basic applications such as the command in- 
terpreter and editor. Some test programs were also de- 
veloped on the MPE XL system to stress special data trans- 
ter cases, such as large writes* large reads, and stress con- 
ditions of control requests. These ran in conjunction with 
the XXPAD tool un the PAD side. 

In its first versions, the XXPAD tool ran on an MPH V 
system (Fig. 9). When the XL version of the HP NS X.25 
software became available, it was possible to migrate to 
the MPE XL system using a loopback configuration. The 
XXPAD tool accessed the DTC through the NS stack (sys- 
tem-to-system) and then looped back on the network to 
enter another SNP card on which the connection was 
routed to the FADSUP module as formatted by the XXPAD 
tool [Fig. 10). The XXPAD tool eliminated a great deal of 
hardware and test setup for the tests implying multiple 
connections. 

To determine when to end the quality tests, each quality 
engineer logged the time taken for each test and the number 
of bugs encountered, This data was input to a software tool 
along with a measure of the quality level we wanted to 
reach. Using the Musa model, *' the tool gave us a weekly 
forecast of the end of the tests. Two months before the 
scheduled end of the tests, the weekly forecasts became 
stable, indicating the same date for the end of the tests, 
Maintenance Testing. In the maintenance phase of the 
PADSUP lask t the functional test suite continues to be 
maintained with the message machine, Each time a new 
version of the PADSUP code is built, it is validated against 
the test suite. It requires some extra w r ork to maintain the 
test suite. The reference files must be kept up to date, and 
because the test coverage is high, any small change in the 
code causes a modification in the result of the tests (he., 
the difference betw r een the reference files and the output 
files] that has to be manually validated. But the test suite 
ensures a high level of quality and confidence when a new 
version or patch has to be delivered on a light schedule. 
We are also working with the real hardware environment, 
of course, and with the XXPAD environment because it 
allows automatic regression and reliability tests in a realis- 



tic environment- 
Conclusion 

The PAIJ support in the DTC architecture offers remote 
access to HP 3000 MPE XL systems in a PAD multivendor 
environ ment by masking all vendor-specific: or nonstan- 
dard implementations without adding code or configura- 
tion complexity. It improves both performance and reliabil- 
ity by using the existing terminal I/O path on the MPE XL 
system. Offloading of all data editing from the host to the 
DTC increases throughput and connectivity by allowing a 
single network access for several systems. Modularity of 
both design and code has been preserved to make the PAD 
support task reusable in future products. 

Formal methodology has been used throughout the de- 
velopmenL The use of structured analysis, structured de- 
sign, and formal testing at different levels, all with the 
permanent collection of metrics, has been fundamental to 
the success of the project. While such techniques cost us 
time in the first phases of the development, they saved a 
lot in the integration and test phases and left the product 
in good shape with regard to maintenance and expandabil- 
ity. 
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An Object-Oriented Message Interface for 
Testing the HP 3000 Data Communications 
and Terminal Controller 

Creating a general-purpose message compiler! decompiler 
using symbolic expressions, expert systems concepts, 
object classes, and inheritance reduces software testing 
overhead and improves test readability and portability, 

by Frederic Maioli 



THE HP 2345 A DATA COMMUNICATIONS and ter- 
minal controller [DTC) t which operates with the 
MPE XL 2.0 operating system, provides access to 
X.25 networks, PAD (packet assembler/disassembler) sup- 
port, asynchronous terminals and printers connected lo- 
cally or through modem links, back-to-back connections, 
and other capabi lilies. Ail of these services can be shared 
by multiple MPE XL systems connected through a local 
area network (LAN). With the hack-to-back feature, a DTC 
can work without a host. 

The HP 2 345 A DTC software is based on a multiproces- 
sor, multitasking operating system. In this system, parallel 
processes or tasks communicate among themselves by ex- 
changing messages. 

An important step in developing a task Is testing it. This 
is done by building a message machine, a program I hat 
simulates the message environment of the task under test. 
During the development of the DTC network software, sev- 
eral message machines were written in the MPE XL operat- 
ing system and on HP 9000 Series 200 Pascal workstations. 

Reusing an existing message machine can seem very at- 
tractive to someone starting a new project. However, even 
when this can be done effectively, each version will usually 
be maintained separately, and the benefits of having some 
common code are gradually lost. 

Looking for a better solution, we have used object- 
oriented concepts 1o write a message machine for testing 
the HP 2345 A DTC PAD support software (see article, page 
63). The program is declarative rather than procedural This 
makes it smaller in code size, more reusable, and very easy 
to adapt to new message structures. The main drawback is 
a decrease in performance, which can be overcome by run- 
ning the tests on a more powerful hardware platform. 

Task Interaction 

As already mentioned* a task is a process inside the DTC. 
A byte-code message is a sequence of bytes that a task 
sends to another task. The syntax of the different messages 
a task can send or receive constitutes its message interface. 

Each task maintains its own behavior as it interacts with 
its environment by sending and receiving messages, Test- 
ing a task consists in checking its behavior by sending it 



a sequence of messages or a message script. The tested task 
reacts to the message scripl by sending back a sequence of 
messages that constitutes a message trace. 

A message script file is written in a message source lan- 
guage and is interpreted by the message machine, which 
sends the corresponding byte-code messages (see Fig. 1). 
The advantage of having a message source language and 
an interpreter is the readability of the message scripts. This 
also makes it possible to send a message from an interactive 
interface, run a message script in step-by-step mode* or put 
I lie tested task in a determined state (to debug if, for exam- 
pie]. 

The message machine catches any message sent by the 
tested task in its byte-code format, translates it to source 
format, and logs it in the message trace file, Translating 
from source to byte code is called message compilation, 
and the reverse operation is called message decompilation. 

The complete (ask lest is a set of message scripts that 
test as much as possible of the task's behavior. 

In the process of maintaining the DTC software, new T 
versions of a task may be released. Compatibility of the old 
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Fig. 1 . To test a task, tne user creates a message script. The 

message machine translates this script to byte-code mes- 
sages that simulate the environment of the task under test. 
The tested task's responses are returned to the user as a 
message trace. 



74 HEWLETT-PACKARD JOURMAL DECEMBER 1990 



)Copr. 1949-1998 Hewlett-Packard Co. 



and new versions is checked by running the same task test 
on both versions and comparing the respective message 
traces. This operation is called a regression test because 
the comparison is expected to validate the new version's 
compatibility. 

le usual way to run a regression test is to run a compart 
son program such as the HP-UX diff utility, which searches 

i\\ differences between two message trace files* 

An Example 

To illustrate these concepts, let us consider a protocol 
for communication between a task named device and a task 
named server, These tasks have been chosen for purposes 
of this example, but one can imagine that the device task 
manages a set of RS-232 terminal links, while server handles 
a computer system's I/O. 

Pig, l shows an example of a message exchange between 
the two tasks server and device. Five different messages can 
be exchanged. The open_session message signifies that a de- 
vice has become active and requests that a session be 
opened (logon). The close.session message is senl when a 
device logs off, The write message sends data to a device. 
The readjine message occurs when a device enters a Line 
of Eext. The read_break message signifies that a break inter- 
rupt key signal has been received from a device. 

The byte-code syntax of these messages is described in 
Fig. 3. The information inside a byte-code message is struc- 
tured in fields. The message_code field is a 2-byte integer 
containing a constant related to the type of message. The 
desLtask field is one byte long and is used by I he operating 
system to identify the task the message is going '<> In this 
example the ASCII value is 25 for the server task ami M for 
the device task. 

The data Field is a string of bytes representing the content 
of a write or read message, The dataje ngth field is a 2-byte 
integer field representing the length i»i the data string in 
bytes. 

The break_code field is a I -byte field I hat distinguishes 
the read _ line message (value — 0) from the read_break message 
(value = 1 ). These messages have the same message coda. 
The dev_num field is a 2-byte integer that identifies the 
hardware device managed by the device task, 

As mentioned above, our message machines define a 
source language associated with the byte-code message syn- 
tax. Examples of source messages are; 
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Fig, 2. Messages exchanged between the two tasks server 

and device 



open_session desLtask 

read, line dest. task 

read_break desLtask 

dose_session desLtask 



25 dev_num; 30 
25 dev„num: 30 
25 dev_num: 30 
25 ctev_num: 30 



data: listf.2' 



In this example, each line represents a message to server, 
which is identified by the desLtask value 25. The first sym- 
bol in a line identifies the message. It is followed by a 
-'i|iji'iu:e f)f Identifier/value pairs. The identifier is a param- 
eter name (terminated by :) corresponding to a field in I he 
byte-code syntax, and the value is the value! of this param- 
eter in the message. 

The byle- code fields corresponding to parameters in 
source messages are called parameter fields. Examples are 
desLtask. dev_num. and data. Not all the fields of a byte-code 
message are parameters in the source syntax, There are also 
constant fields, or selector fields, whose value identifies a 
unique message structure- Examples are message_code and 
break_code. Finally, there are fields, such as data length, 
whose values depend cm the values of other fields. These 



open session 



close.sessjon 



't-.nJ Jir.i:- 



read_brt?uk 



mesnge_cotfo:20 



inn»ge_c;pd«:2l I I mn»gt_cfHto:22 I I message code: 23 



mt6»age_£od« 2$ 




Fig. 3. Byte- code syntax of the 
messages tn Fig. 2. 



DECEMBER 1990 HEWLETT-PACKARD JOURNAL 75 



)Copr. 1949-1998 Hewlett-Packard Co. 



are called computed f iritis 

Notice that the list of source messages given above could 
be used as a message script by a message machine and 
would correspond to a test of server. This reproduction of 
the dialog of the example of Fig. 2 would make the message 
machine produce the message trace: 

write desLtask: 32dev_num: 30 data XYZMPEXLA30 QO.TUE. 

MAY 29, 1990 
write desLtask; 32 dev_num; 30 data: ':' 
write dest_task:32dev_num:30data: FILE1 FILE2FIL' 
write desLtask : 32 dev_num : 30 data: ' :' 

Conventional Compilation and Decompilation 

When one wants to reuse a message machine and adapt 
it to new message forum Is. most of the changes consist of 
rewrilhiu ihe message compilation and decompilation pro- 
cedures, 

There is a procedure compile. message, which takes as input 
a line of message source code and returns I lie byte-code 
format of this message: 

procedure compNe_message(!ine) 
local variables: idf, result 
read an identifier idf in line; 
if idf - 'open_session' { 
let result be a new string 

write the integer 20 on 2 bytes in result: r message_code V 
compi I e_par amete r_i n_ty p e_si z e ( I i ne ; dest_tas k' .result. 

integer, 1); 
co m p iie_pa r ameter _i n_ ty p e_siz e ( I i ne f de v_nu m ' , resu It , 

integer ,2); 
return result; \ 
else if idf = close_session' 

else if idf - write' 



else error('bad message name) 

end if 
return result 

end procedure 

In this procedure, the message type is identified. Then 
the byte-code message is synthesized parameter by param- 
eter in the following procedure; 

procedu re compi I e_p ar am eter_t n_ty pe_s i ze (I i n e , param _ name , 

result, type, size) 
local variables: idf 
read an identifier idf in line; 
if idf and param_name are not the same then errorf bad 

parameter name "); 
if type = 'integer' then 
read the integer int in decimal format in line; 
write the integer int in binary on size bytes in result; 
else if type = string' then .... 

end if 
end procedure 



Decompiling a message is slightly more difficult. First, 
one must match a message struclure to a byte-code format. 
This is done b\ a derision tree lhal tests values in fixed 
fields: 

procedu re decompi le_m essage( byte_ m e ss age ) 
local variables : message_code, break_code 
let message_code be the integer from byte 1 to byte 2 in 

byte, message; 
if message_code = 20 

retu rn d ecompi ie_o pen _sessio n {by te„nrtes sage) ; 
else if message_code - 21 

else if message_code * 23 

let break_code be the integer at byte 6 in byte_message; 

if break_code - then 

retu rn d ecompi le_re adj in e( byte_m e ssag e ): 
else if break_code - 1 then 

end if 
else errorf bad message code 1 ); 
end if 
end procedure 

There is a procedure for each message structure, which 
is called when the message structure has been determined. 
For example, the one corresponding to the open_session mes- 
sage is: 

p rocedu re d ecompi !e_o pen .session ( byte_message) ; 

local variables: result 

let result be a new string; 

write YequesLsession" in result: 

d ecompi I e_desLtas k_i n{byte_messag e , resu It) ; 

decompile ,dev_num{ ,„ ); 

return result; 
end procedure 

For each parameter, there is the reciprocal of the param- 
eter compilation procedure. One example is: 

procedure deco m pi I e_dest_task_i n(byte_m essage.result) 
let desLtask be the integer at byte 3 in byte_message; 
write desLtask' and desUask in result 

end procedure 

Writing the message compilers and decompilers in al- 
gorithmic language is simple for a few messages, but it is 
more difficult for 50 messages, a typical number for the 
message interface of a real DTC task. The message compilers 
and decompilers are programs that are very dependent on 
message byte-code and source syntax, so they contain much 
redundant information, 

This approach has several drawbacks. First, the byte- 
code-to-message matcher is complex, difficult to validate, 
and difficult to maintain when new message structures are 
added. Second, some fields are common to several mes- 
sages. It would be possible to write some partial compi la- 
tion and decompilation procedures common to several 
messages, but modifying the syntax of one message could 
require modifications in other messages. Third 1 when 
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changing or adding a field, there are interdependent mod- 
ifications in the compiler and in the decompiler. This 
creates the need for a compatibility test between compila- 
tion and decompilation procedures. 

A further drawback of the conventional approach is 
for the same script and the same tested task, some param- 
eters can have different values in message traces that do 
not constitute n test violations- For example, there 

can be a message trace that contains some information 
about the current date: 

write desLtask: 32 dev_num; 30 data: XYZ MPE XI_ A.30-00. TUE, 

MAY 29, 1990 

This causes useless differences between message traces 
that increase the difficulty of analyzing these files and of 
automating the tests. 

A final drawback of the conventional approach is that 
no message documentation is maintained as the message 
machine evolves. The documentation used in reality is the 
source listing of the compilation and decompilation proce- 
dures. 

Using Symbolic Programming Concepts 

Object-orieoted languages provide symbolic expression 
facilities. This gave us the idea of representing the message 
source language using symbolic expressions, This is the 
same as using lists in Lisp. 1 arrays in Smalltalk, 2 or terms 
in Prolog 3 , 

The traditional source message; 

open session desLtask: 25 dev_num: 30 

is equivalent to the symbolic expression [using Lisp lists, 
for instance): 

(open. ^session (dest .task 25) (dev_num 30)) 

More generally; any source message will have the syn- 
tax:* 

(<message name> (< parameter name. ■ parameter value )*) 

There are significant advantages to the use of symbolic 
expressions, hirst, it is easy and improves readability to 
give name values Instead of integer values to some param- 
eters* For example, (desLtask device) is belter than (desLtask 
32), 

Second, intelligent regression is possible. When com pin- 
ing message trace files, the HP-UX duff utility provides a 
byte-to-byte comparison, It is a better solution to compare 
two symbolic expressions by traversing their structures 
[like the equal function in Lisp 1 ), This is because; 

■ It is more efficient to compare symbols than the bytes 
of strings. 

■ One can customize the comparison algorithm by not 
comparing some parameters that contain variable infor- 
mation, such as the current date. 

T ln all syntax description m true paper, syntax deiinrtion is dono^ri by SyfWflli ' 

;< alternatives are separated by . and syntax concatenation is denoted 

by >:■'■ i| i .m 



■ The formatting of regression violations is easily im- 
proved. The incorrect messages are displayed rather than 
the incorrect lines. 

■ it to recover automatically after a nonregression 
violation and continue the comparison, since the com- 
parer synchronizes on messages rather than lines. 

A third advantage of using \c expressions is auto- 

matic indentation. Some environments provide indenting 
formatters for symbolic expressions (such as Lisp pretty 
printing 1 ). Using It large source messages with many pa- 
rameters are very readable: 

(command^narne (pararai vail) 
(param2 va\2} 
(param3 va*3) 



> 



We used Smalltalk arrays and found it simple to imple- 
ment such a printing formatter. 

Specifying the Compiler and Decompiler 

The most important drawback in adding or modifying a 
new message format in the message compiler and decom- 
piler is that the same information for message translation 
is coded at least twice, once in the compiler and oncp its 
the decompiler, This is a source of errors, code overhead, 
unreadability, and nnnportability of the message machine. 
The question arises: Wouldn't it be possible to define only 
once the necessary information for both compilation and 
decompilation? Many symbolic programs define a data for- 
malism and an interpreter over this formalism, Most of the 
behavior of these programs is embedded in spei Miration 
data bases rather than procedures. This is the case for most 
expert systems, which contain an interpreter [the inference 
engine) over a specification of the expertise (the rule base, 
which is a database). The (mesHqil is then: Does there exist 
realism to specify the mapping between the source 
format and the byte-code format of a message, with general- 
purpose compiling and decompiling procedures? 

We have been able to answer this question in the affirma- 
tive. We have obtains! an efficient specifiestiQE formalism, 
which now covers 95% of our message compilation and 
decompilation, The remainder is implemented convention- 
ally. 

Our formalism makes the distinction between two kinds 
of fields in messages, There are fields with a statically 
known position in the byte-code syntax, and fields with a 
statically unknown position- "Statically" means that th^r 
field is always located at the same place in the byte code. 
This location does not depend on the message content, For 
example, the desLtask field in all messages has a statically 
known position [at byte 3] in all byte-code messages, but 
the data field does not have a statically known position, 
since the end position of the field is known only when the 
message to be compiled or decompiled is known. 

To simplify, we will call fields with a statically known 
position positioned fields and fields with a statically un- 
known position unpositioned fields, The specification for- 
malism only covers positioned fields. Given a message's 
specification, we have written Urn general-purpose compi- 
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lation and decompilation procedure that interprels the 
specification. 

The following symbolic expressions describe the specifi- 
cation of the messages of the example above; 

■ Declaration of all the parameter fields of all the messages 
and their types (integer, string, or symbolic Integer which 
translates a string to an integer); 

(parameterJieJds 
(devnum Integer) 

(desLtask (Symboticlnteger {'device' 32) 
('server' 25))) 
(data String) 
) 

■ Declaration of constant and computed fields: 

(constanLfieids message_code break_code) 
(computedjields datajengtti) 

■ Declaration of the size (in bytes] of each field in the 
byte-code messages (positioned fields only): 

(fields_size 
(message_code 2) 
(desUask 1 } 
(dev_num 2) 
(datajength 2) 
(break_code 1)) 

■ Specification of all the messages. For each message, there 
is an expression for called a metamessage, A metames- 
sage formalizes the notion of message structure. First, 
there is the corresponding message name, then three 
subexpressions called melo fields. The parameter Jields 
metafield contains all parameter field names. The con- 
stant fields metafield maps values to constant fields. The 
byte Code .order metafield defines how the fields are or- 
dered in byte code. 

(message. specs 
(open session 

(parameter_fields dev_num desLtask) 
(constantjieids (message_CQde 20')) 
(byteCode_order message_code desijask devjium)) 
(ck>se_ session ...) 

(write ...) 

(readjine 
(parameter_fields dev_num desLtask data) 
(constantjieids (message_code 23) 

(break_code 0)) 
(byteCode^order message_code desLtask 
dev_num break_code)) 
(read_break 
(parameterjields dev_num desLtask) 
{constant Jields (message code 23) 

(break_code 0)) 
(by1eCode„order message_code desLtask 

dev_num break_code dataJength)) 
) 



The message specification is now completed. Before 
using it to peri o j in compilation and decom pi lation, there 
is an initialization step called the metacompi Jul ion phase 
where the specification is checked for correctness, Exam- 
ples of checked constraints are field name consistency and 
collisions, and field juxtaposition consistency in each mes- 
sage. 

The metacompi la t i on a I so generates intermediate results. 
A field_position metafield is ail tied to each metamessage to 
complete byteCodejarder information. It relists the byte-code 
fields, adding to each of them the pair < first byte, last byte>. 
This pair defines the position of liie field in the byte-code 
string: 

(message^specs 

(read_break 

(byteCode_position (message_code 1 ) 
{desLtask 2 2) 

(dev_num 3 4) 
(break_code 5 5))) 
) 

A constant field always has the same position in all the 
messages that contain it. Otherwise, it would be impossible 
to map a byte-code onto a message structure. The positions 
of all constant fields are kept i n the constanLfiekLposition list; 

(const anLf i e fd ^positio n 
(message_code 1 ) 
(break_code 5 5)) 

The decoder tree is used by the decompiler to identify 
a message from a byte code. In the example, it is; 

(decode rjree 
(message_code 
(20 requesLsession) 

(21 close_session) 
(22 write) 

(23 (break_code (0 readjine) (1 read_break)))) 
) 

The syntax is: 

<decoder_tree> :: = 
<inessage name>; 
{<:constantfield name> (< constant field vatuexdecoder_tree>)*) 
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It is used in the following function, which is used by the 
decompiler: 

function decode_bytesft.str) 

* find the message structure name associated with the byte code 
str by performing the tests specified in the decoder tree t • 



The general-purpose compiler looks as follows (for simplic* 
ity, type checking and parameter value translation have 
not been indicated here); 

function compilers!) 

* translate the source message 1st m byte code * 



local variables: x,y T val.cName,n,v 1 ..-v ni t v ~t n -* 

rf t is a name, return t; 

t has the form (cName <vi Wi - (V n ki) 

otherwise error(" bad decoder tree"); 
let x and y be such that the constant. fteld_position list contains 
(consiant_fie!d_posftion ... {cName x y) ...) 

let val - the integer coded from byte x to byte y in str 



local variables: m,n,p v .p n .v- e^.w-, .w m4 

p,b, o p ,x, . x p ,y, .y pi i,j,result 
suppose 1st has the form (m <p n v^ ... (p n v n )) 

find the metamessage of the Form 
(rn (parameterjields p<, .„ p n ) 

(constantjietds (c, w,) ... (c m w m )) 
(byteCode_posrtion [b t x^ y T ) ... (b p x p y p ?) 
otherwise error( "syntax error "i 



let f , 1 - i - n such that v, = val 

otherwise errorfundecodabie byte code"); 
return decode.bytesltj.str); 
end function 

The decoder tree takes the place of the decision tree in 
the conventional decompilation procedure, ll is automati- 
cally generated at the metacompilation step: 

proced u re gene rate_d ecoder_ t ree( I st ) 

P return a decoder tree mapping one of the message names in the list 
J st from a byte code string *i 

local variables: n,v 1 ..v n ,i,mj .c.S.v^.sublist.subdecodec result 

suppose 1st has the form (m-i .„ m n ) 

if n - 1 return rr^; 

endif 

P find a constant field that discriminates messages V 

find a constant field c such that 
for alJ i. 1 <= I <= n consider the metamessage: 

(nrij ... (constanLfields ... (c Vj) ,..) ...} 

and let S be the set of all Yj 

and S contains at least two elements 
if not found error ("Impossible to buiJd a decoder tree') 
end find 



P initialize byte code ' 

let result be an empty string 

P explained later " 

call the procedure attached to m to compute computed field values 

for 1 < - j < p 

if \ exists such that bj - ft then 
* code constant field 7 

code w, as integer From byte x, to byte y, in result 
else if j exists such that b 1 =* pj 
P code parameter field 7 
code Vj as integer from byte x, to byte Vj in result 
else if ... P and so on for computed parameters 7 
end if 
end for 

4 explained later '■' 

call the procedure attached to m to compile un positioned 
parameters to result 

end function 

The decompiler is as follows: 

function decompile(str) 

P translate the byte code string str in source message 7 

local variables: t, m.n,p 1 . .p ni p,b T , bp^ ..x p ,y t . y p ,result. 

i.j. val 



let result - an empty lis! 

P recursively build the tree ' 

for all v k in S 

sublist c the list of m, such that v, = v k 

su bd ecod e r g ene rate . d ecoder J re e ( s ubl ist ) 

put subdecoder to the end of result 

end for 

add c to the beginning of result 

return result 
end procedure 



let t - the decoder tree specification: 
let m = decode_bytes(t,str); 

find the message specification m message_specs: 

(m (parameterjields p 1 .... p n ) 

fbyteCode„position (b t x t y^ ... (b p x p y p )) 

) 
P explained later \ 
call the procedure attached to m to decompile unpositioned 

parameters and computed fields from str 

let result be the list made up of the single element m 
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for 1 < = \ < = n 

if j exists such thai b t = p, 
r positioned parameter V 
vaJ the integer coded from bytes Xj to y t in str 
else 
r explained later V 

else val - value computed by the procedure attached to m 
endif 

add (p, val) at the end of result 
end for 
return result 
end function 

The different statements commented r explained later ■ 
refer to conventional procedures necessary to compile and 
decompile unpositioned fields and compute values of com- 
puled fields. These procedures (not described here) repre- 
sent no more than 5% of the message machine implemen- 
latinn [in noncomment source code lines of Smalltalk). 

As a result of this design, to add, modify, or remove 
message struelnres it is only necessary lo edit the message 
specification list, adapting a few procedures for un- 
positioned fields, and running ihe metacompilation step, 

Using Objects and Inheritance 

The symbolic message machine was implemented in 
Smalltalk/V on a personal computer and then ported to a 
C-coded Smalltalk implementation on the HP- UX operat- 
ing system to interface with the test environment of the 
DTC operating system, A Smalltalk interpreter provides 
the interface to the DTC operating system lest environment 
on HP-UX. The message machine and all tests are im- 
plemented in this interpreter. lis expression power and 
openness g& powerful advantages that help develop and 
run the tests more efficiently lhan before, 

A number of facilities allowed us to write an efficient 
and well-adapted implementation. One adaptation was the 
use of array objects to represent symbolic expressions. 
Another was the use of classes and inheritance to imple- 
ment objects representing metamessages, metafields. and 
positions. In particular, different metamessages contain 
much common information. The immediate sol u I km con- 
sists of implementing partial message descriptions, rela- 
tions between them, and metamessages to propagate 
metafields and field structure information. Metamessages 
also refer to procedural information that is to be propagated 
along these relations, Therefore, it was helpful to map 
classes and superclasses to metamessages and partial de- 
scriptions, and the basic class inheritance mechanism to 
the propagation relation. 

Thus, a class is created for each message and the 
metafield information is obtained from methods — that is t 
by inheritance. Procedures related to un positioned fields 
are treated in the same way. For example, to obtain 
metafield information on the write and open_session mes- 
sages, one creates the classes; 



DtcMessage 

WriteMessage. subclass of DtcMessage 

Open Session Message, subclass of DtcMessage. 

OtcMessage provides information common to all messages. 
Specifying values of the parametersjield m eta para meter con- 

sisfs of implementing rh^ following methods: 

method parameterJietdsO on class of DtcMessage 
return the Array (dest_task dev_num) 

end method 

method parameterJieldsO on class of Write Message 

resull . - result of sending parameter^ elds to superclass of self 
return concatenation of result and the symbol data 

end method 

Other adaptations were: 

■ Metafield information is cached in sets, dictionaries, and 
ordered collections for better performance, 

■ The compile and decompile procedures are methods oi 
the abstract message class DtcMessage, 

■ A new metafield, example, is used in a general-purpose 
test procedure to build an example source message. It is 
also used in an automatic documentation procedure. 

Conclusion 

The object-oriented message machine has been used Ln 
the HP 2345A DTC PAD support project (see article, page 
63J. Validating a new version of the PAD support software 
only requires starting an HP-UX shell; no further human 
intervention is needed. 

After having being successfully used by the PAD support 
projecL ihe message machine proved its ability to adapt to 
a new project, where it is now used. 
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Absorbance detectors, LC ,.,-..-..- 36/ Apr. 
Abstract Syntax Notation One 

32 Feb..25,37 

ACSE (Association Control Service 

Element) ~. 6.31 'Feb.. ILAug, 

Action routines 63.69 Oct . 

Actions, HP Softbench ,. ., fi2.Ju.tie 

Aging* cold-drawn CuBe 88 Dec, 

Air flow simulation ... H2 Oct 

AK (acknowledgment) TPDU 38/Feb. 

Algorithm, circuit simulation 79/Oct. 
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Amplifier. GaAs .„., ................ Bl/Aug, 

Amplifier performance 

prediction »*.......„..» . 78/Oct. 

Amplifier, variable-gain linear .... 91/Aug, 

Analog-to-digital converter 41/Apr. 
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CuBe ..»,. SB/Dec, 
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code (CIRC) 42/Dec, 

CS-80 (Command Sfst HI)) 38.49/Dee. 
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system 58/Dec. 

Dependencies, automatic 



generation ...... 52 June 

Desolvation chamber ,. ... 7Q7June 

Detectors, LC 36/ Apr- 
Development manager. 

HP Softbench 49]une 

Development methodology, PAD 

software 70/Dec. 
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Flip mechanism ,.. 20/Dec. 
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Flow rales, fan 86/Oct. 
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Force sense of touch 26/Dec. 
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FTAM \Fi\e Transfer, Access and 

Management] 24/Aug. 
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Gated delayed self-homodyne 

technique ,,-.<<>, 95/Feb. 

General-behavior resources, 

mwm ..„ 19/June 

Gradient programming 32/ Apr, 

Graphics, HP IVT 21.2ti/Oct. 

Group WSQSB map 50/Dec. 

GP zones ..„ 89/Dec 
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Habit planes ,..„ BQ/Dec. 

Help. HP Soft Bench 57/June 

Hexagonal f^rrile filters 52/Oct 

Hexagonal ferrites «.*,.„ 59/OcL 

High Sierra Group (HSGJ 54/Dec. 
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HP MMS/800 1 <.„., 34/Aug, 

H? MMS/800 services 38/Aug. 
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IC package model verification 74/Oct. 
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IC, pump control 30/Apr. 
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Inductance measurement 75/Oct. 

industrial design, LC . 9/Apr. 

Inheritance, objects 30\34/OcL 

Initialization, autochanger %8fB&&, 

Injector, LC 17/Apr, 

inode 56/Dec. 

Input handling, HP IVI ^,34/Oct. 

lull _;i <ih d personal development 

environment, HP MAP 3.0 50/Aug. 

Integration and test, OSI Express 

card 72 r 75/Feb, 

Intensity noise, laser 89/Feb. 

IntercHent communication conventions 

(1CCC1 , 23/June 

Interferometer, fiber optic 92/Feb, 

Interleaving, CD-ROM file system . 58/Dec. 
Interoperability testing, 

FtP MAP 3,0 38 T 50/Aug. 

Interpreter, Encapsulator 68/June 

1PDE 50/Aug. 

Iris-coupled filter 52/Oct. 

ISO 966G/HSG CD-ROM file system 

standard , ...„..«, 54/Dec, 



Lambert-Beer law .,.., 36/Apr. 

LAN bridge ... 66/ Apr, 

Lands, CD-ROM 36/Dec, 

Language. Encapsulator Descrip- 
tion 61/fune 

Laser measurements ...„.,.„., 87.92/Feb> 

LC/MS particle beam interface ..>« 69/June 

Leak drainage system 9. Apr. 

Level shifter 89/Aug, 

Lightwave receiver „,„,.,.,.., 81/Feb. 

Lightwave signal analysis 80/Feb. 

Line driver 82/Aug. 

Line width measurements, laser ... 93/Feb. 

Link quad , ..... 10/Feb. 

Linking, HP Encapsulator 66/June 

Liquid chromatograph 6, Apr. 

List manipulation. HP TVI 17/Oct. 

LLC [logical link control! 45/Feb. 

Local area network (LAN) 6 6/ Apr. 

Loop-back, OSI Express card ....... 49/Feb. 



M 

MAC (media access control] 45 Feb, 

Magazines, optical disk 22/Dec, 

MAGIC LC/MS . 70/June 

Magnetooptical storage technology . fi/Dec. 
Mail management, LC firmware .. 48/ Apr. 
Mailslot , 21/Dec. 



mailx encapsulation , fiO'l um- 
Makefiles 52 June 

Manager objecls, HP «Solt bench ... 62/] una 

Manufacturing. LC 14/ Apr, 

Mapcont ,.. 9/Aug. 

Mapping, network request ............ 68/Dec. 

Mastering, CD-ROM 39/Dec, 

Mechanical design, optical disk 

autochanger 14/Dec. 

Membrane probe card ..,.,..., 77/June 

Memory controller chip .►,.♦. 15/Feb. 

Memory management, OSI Express 

card 25/Feb 

Menu handling, mwm .«„.„ 22/June 

Merge bits, CD-ROM ..., .. 39/Dec 

Message corn pi I at ion 

decompilation >., 76/Dec, 

Message interface 74/Dec, 

Message interface. Encapsulator , ft 2 /June 

Message machine .„.. 74/Dec. 

Message matching, HP DIS 67/Oct. 

Message script 74/Dec. 

Message Irate 74/Dec, 

Messaging, objects 29'Ocl. 

Metafields , 78/Dec, 

Metamessages .., 78/Dec 

Metering device, LC 20/Apr, 

Mixers, preselected millimeter- 
wave .►.♦♦>-.<,♦.. 49/Oct. 

MMS (Manufacturing Message 

Specification) 31/Aug. 

MMS services ^.„„*.„- r ? «*.-^ r 33/Aug. 

Model, computer air flow 83/Oct. 

Model, IC package 73/Oct. 

Modulation response, laser 88,90/Feb, 

Module design, LC «« 6/A[ir 

Momentum separator ,.„ 70/June 

Multiple symbol registration 64/ Apr. 

Multiple wavelength detector 39/Apr. 

mwm [HP OSF/Motif window 

Manager) „ ., 12/June 

Multivariate statistics ,„,, 78/Qct. 

N 

Native language support 42/June 

Nebulizer .,,„ ,,„ 70/June 

Network management .,..,.„ 55/Apr. 

Noise. LC detector , 37/Apr. 

Notification message 39,53/fune 

o 

Object hierarchy, HP IVI 11/Oct. 

Object-oriented design , f> , 22>29/Oct. 

Object-oriented message machine , 74/Dec, 

Objects ..„ 11,29/OcL 

Objects, HP Encapsulator 62/June 

Offset elimination ....,.,., 85/Aug. 

One-line editables 42/June 

Open Software Foundation (OSF) , 8^7 une 
Optical disk drives, qualification . 35/Dec, 

Optical disk library system 6/Dec. 

Optical library, HP-UX 

integration + , T 11 /Dec, 

OSF/Motif 6.6/June 

OSI addressing ,,.. 19/Feb. 
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protocol « . ..*.. 

OSI Express card 

OSI Express card driver 

OSI object model — 

OSI reference mode J 

OSI system management model 

Output section. 500-MH-/ 
pulse generator ..... 

Output section, variable-slope 
pulse generator 

Overshoot adjustment 

OVRun. OV Admin , OVDraw 60.72 



49Feh. 
.. 8/Feb. 

45 Aug 
56/Apr. 
. 8/Aug. 

79 Aug. 
85 Aug- 
-74 Apr 



PAD support software ..*,. 63/Dec. 

Particle beam interface «,..., 69 June 

Particle traces ■ 86'Oct- 

Pattern matching ........ 64([une 

PDUs {protocol data units) 32/Feth 

Performance. HP D1S 71/OcL 

Performance. OSI Express card 51 /Feb. 

Photoreceiver ... B4/Feb. 

Picker ', 19/Dec. 

Pits, CD-ROM 38/Dec, 

Plunge motion .♦..,..... ........ 15/Dec, 

Polymorphism ... 12,30,34/Oct, 

Pop-up menus, check boxes, and 

pushbuttons, OSF/Motif Il/June 

Power sped rum measurements. 

Laser ,„....... .,>. ■ . .. 94/Feb. 

Preamplifier 82/Aug. 

Precom press ion phase 25/ Apr. 

Pre st elected mixers 49/Oct. 

Presentation layer 3l/Feb. 

Pressure drop ». , 86/Oct. 

Pressure monitoring 34/Apr. 

Primary channel 33/Apr. 

Primitive objects ♦... 62/June 

Principal component analysis 78/Qct. 

Probe cards, wafer test 77/June 

Process defects, diagnosis 80/Oct. 

Process integration »...,« fi5/June 

Process model, OSI Express card . 24/Feb. 

^ifications ........... 65/June 

Profiles, X.3 67/Dec. 

Program test, HP Softbem:h 5 4 /June 

Programmable pulse generators .. 64 /Aug, 
Programming, OSF/Motif 

widgets 26/Junn 

Project management, HP IVI ... 7/Oct. 

Proportional noise 37/Apr. 

Protocol interface, HP DIS .. B2/Oct. 

Protocol module interfaces, OSI 

Express card 20/Feb, 

Protocol Specification Language ,. 63/Oct. 

Protocols, X.25 network 65/Dec. 

Pulse generators, 500-MHz 64/Aug, 

Puin|j module, LC 24/Apr. 



Qualification, optical disk drives . 35/Dec. 

Quality engineering, LC ., ........ 11/Apr. 

Quality function deployment 

(QFDj 9/Ocl. 

Quaternary pump module 32/Apr. 



Real-time procedure tracer, OSI 

Express t:ard ... 

Receiver, lightwave 

Red book standard, 

CD-ROM 39 

Reed-Solomon product-tike 

code 39 

Region access map ,.,.,......... 

Register sets - 

Reliability, LC ..... 

Reliability model, software 

Remote builds 

Remote execution 

Request message. 

HP Softbench W 

Responder process, FT AM 

Reuse, code ........... 

Reverse optics detector 

Rewritable optical technology 

RIN [relative intensity noise) 

Ripple, flow ..... .,,.,* 

Ripple measurement .... 

RLC measurement in VLSI 

packages ............ 

Roller, flow 

ROSE ( Remote Operation Service 

Entity] . -., - 11 



57/Feb. 
81/Feb- 

,42/Dec. 

507Dec> 
9 F-|. 
12 Apr 
46/fune 
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,b3lune 
28/Aug. 
44/Apr. 
39/Apr. 
.. 8/Llec. 
90/Feb. 
26/Apr, 
34/Apr. 

73/Oct. 
2 8/ Apr. 

,22/Aug. 



Sampling unit. LC - 19/Apr. 

SAP selectors. OSI Express card .. 20/Feb. 

Saturation, servo ..--. IB/Dec. 

Scanning absorbance detector 38/ Apr. 

Scenario interpreter agenl. OSI Express 
card 7.1 I'i'i. 

Schemes, I IP Softbench 41/Junr* 

Schottky noise 37/Apr. 

Security, CD-ROM 49/Dec. 

Security, network 68/Dec, 

Security toolbox, CD-ROM 49/Dec. 

Self-homodyne measure- 
ments - 94,95/Feb. 

Sense of touch 26/Dm.. 

Service provider process* 

HP MAP J.U 12,28,35/Aiii>. 

Servo design, optical disk 

autochanger 24/Dec, 

Session layer ......... 29/Feb, 

Shaper 82/Aug. 

Shrinkage, cold-drawn CuBe RB/Dec. 

Signal-to-noise ratio, LC 

detector ... 37/Apr. 

Simulation, statistical ....... 78/Qct. 

Single -frequency laser m « mi 
ments 92/Feb, 

Slope generator 85/Aug. 

Slow slopes , , 85/Aug. 

SoftBench environment 35/June 

Software development environ- 
ment , 36/Iune 

Software environment tools 48/]une 

Software integration. 

HP MAP 3.0 54/Aug. 

Solvent delivery system ,. 24/Apr 

Specifications, projection ... 80/Oct. 



Spheres, barium ferrite 52,61 Oct. 

Spike generator ,. — a... 70 Aug. 

State machine. HP W\ 34/Oct. 

Statement table 67/Jime 

Static analysis, OSI Express card . 51 /Feb. 
Static analyzer 54 lone 

Statistical simulation i Oct, 

Structure definition utility. OSI Express 

card . ... 59/Feb. 

Symbolic programming 77 "Pec 

Syndrome. CD-ROM 43T 

System interface, OSI Express 

card Z7/Feb. 

Swapping, optical disk il/Dec. 

T 

Tables. LC firmware 48 Apr. 

Task configuration. LC - 48/Apr, 

Tasks. DTC ...„„, S4/Dec. 

Temperature compensation. 

filter drive -. ■■■ 55/Oct. 

Testing. HP MAP 30 29,50/Alim 

Testing, CD-ROM drive 45/Dec. 

Testing, mwm .< 25/June 

Testing, OSI Express card , 50/Feb. 

Testing, PAD support 

software ... 6870/Dec. 

3D appearance. OSF/Motif 14/June 

3D appearance, HP IVI 40/Oct. 

Timer management, OSI Express 

card *„ 26/Feb. 

Timing generator 71/Aug. 

Timing IC 69/Aug. 

Timing parameter generation 67/Aug. 

Tool communication 38/June 

Tool execution 41/June 

Tool integration 59/June 

Tools, software development 48/June 

Tool triggers B4(fune 

Touchdowns, wafer probe 82/June 

TPDU (transport protocol data 

unit) .. 3*i/Feb, 

Tracing, OSI Express card 71 /Feb. 

Translale mechanism 17/Dec. 

Transport interface compatibility 

layer .., 69/Apr. 

Triggers, event 39/June 

Triggers, tool • .■ 64/June 

TSDU (transport service data 

uniM - 35/Feb. 

Two-sphere barium ferrite filter ,. 52/Oct. 

u 

Uniaxial anisotropy > 59/Oct. 

Upper layer architecture, 

HP MAP 30 11/Aug. 

Upper layer interprocess communication 

(ULIPC] 4G\41/Aug, 

Upper layers t OSI Express card ... 28/Feb. 

User interface, Encapsulator 62/fune 

User interface management 44/fune 

User process, HP MAP :lo . 12, 2 7.3 5/ Aug. 
Utility commands, CD-ROM 

drive 52/Dec. 
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Valve, active LC inlet 27/Apr. 

Variable-gain output amplifier .... 91 /Aug, 
Variable- si ope pulse generator .,,. 64/Aug. 

Variable stroke volume 2f;,29/Apr, 

Variable wavelength detectoi 3 8/ Apr. 

Vertical carriage . 15/Dhc. 

Virtual file store (VPS J ... 24/ Aug. 

VLSI package RLC measurements . 73'Od. 
vnode .<.*.„■>.«*.«•- ■■■ 55/Dec. 



w 

Wafer test prone >,.>,>,.„,. .... 77/June 

Wait fime ii/Etec. 

Widget program ..*„.„,•■;.;,;* 30/June 

Widgets 26,27 Jum 

Widgets and windows 16/June 

Widgets, HP IVJ 22,39/Oct. 

Windowing, HP IVI 21,24/Get. 

Windows. HP Open View SQ^'Apr, 



X 

X.2. r > 37/Feb, 

X.25 PAD support 6 3 /Dec 

X.500 17/Aug 

X Wind nw System „ , 6,2fHim.- 

Y 

YelJow book standard. 
CD-ROM .,., mA2ffie& 
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HP 1050 Series liquid chromatography modules Apr, 

HP 2345A data ertmiTumf Cations and terminal controller ... Dec, 

HP Series 6100 Model GOO/A HP-IB CD-ROM drive , Dec, 

HP Series 6300 Model 2QGB/A rewritable uplical disk 

library system .„.„. , , Dtu:. 

HP 8130A 300-MHii variable-slope pulse generator Aug, 

HP 8131A 500-MHz pulse generator Aug. 

HP 11974A/Q/U/V preselected mixers ,,.., Oct. 

HP 1I980A fiber optic interferometer .... Feb. 

HP 59980A particle beam LC interface „.„ „■■„;, June 

HP 70810A lightwave receiver t Feb. 

HP 714QUA lightwave signal analyzer .;.„.« Feb. 

HP 71401A lightwave signal analyzer .„„. Feb, 

HP 79853A variable wavelength detector Apr. 
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Effect of Fiber Texture on the Anisotropic 
Dimensional Change of Cu 1.8 wt% Be 

The dimensional changes in cold-drawn Cu1.8 wt% (11 A 
at%) Be rods resulting from aging are investigated. The 
dimensional changes are nearly isotropic for as-quenched 
specimens but are anisotropic for cold-drawn specimens. 
The theoretical dimensional changes predicted based on 
the degree of preferred orientation, the crystallographic 
data of Cu-Be, and the geometry of the specimens agree 
with the experimental results. 

by Frank E. Hauser and Nguyen P. Hung 



COPPER BERYLLIUM (Cu~Be) ALLOY is tradition- 
ally used for spring connectors in the electronic in- 
dustry because it has high conductivity, is plalable. 
is low in cost, and has high strength with a relatively low 
modulus of elasticity (good spring characteristic). The ma- 
terial is usually machined when it is still soft after being 
solution-quenched and cold- worked. Machined parts are 
then precipitation hardened (aged) at an elevated temper- 
ature. This nearly doubles the mechanical strength without 
significantly changing pi stability or conductivity, 

For precision components with tolerances on the order 
of ±5 ftm (±0.0002 in), the use of Cu-Be alloy is limited 
because of the inconsistent dimensional changes that ac- 
company aging, The shrinkage of Cu-Be during aging has 
been investigated by several other researchers 1, ^ who as- 
sumed isotropic shrinkage of this material This paper in- 
vestigates the anisotropic dimensional changes of Cu-Be 
during aging, and discusses the effects of cold drawing 1 
aging time, and aging temperature. 

Experiments 

Table I lists the properties of the tested material The 
tested bars were centerless ground with minimum material 
removal, then machined into cylinders 25 mm (1.0 in) long, 
Next, the ends of these cylinders were ground parallel 
within 1.25 /aid (50 jwin). The specimens were ultrasoni- 
cally cleaned, then aged at different temperatures from 
200°C to 480°C (390 Q C to 900°F) in a mixture of 95% 1SL 
and 5% H 2 to minimize any measurement error caused by 
surface oxidation 

All samples were measured before and after each aging 
period. The measurements were performed in an environ- 
mentally controlled room in which temperature was held 
to 23±1 D C Diameters were measured with a scanning He- 
Ne laser system with resolution of 0,2 jim [10 ^i\u] and 
accuracy of ±0.8 /im ( = 30 /iin). The specimen lengths were 
measured with an indicating system with a resolution of 
0.2 /im (10 jxin) and accuracy of ±1 pm (±40 /iin). 

An x-ray diffraction method was used to characterize the 
sample texture. Inner and outer pieces of a bar were re- 



moved on a traveled wire electrical discharge machine* as 
shown in Fig, la. The diffractometer was set up for CuK^ 
x-rays with a Ni filter and a 0.4° beam split. The areas 
under the (200) and [111] diffraction peaks were measured 
with a planimeter and compared with data for copper pow- 
der. 

Table I 
Composition and Size of the Test Pieces 

Material: Cu l.B wt% Be 0.2;j Co 0.10 Si 
Condition: Solutionized at 775 D C [1425°F), 
Water-Qu enche d 

Co Id -Drawn, % Diameter Change 
10 20 30 



Size (mm) 
Size (in) 



14.27 
0.562 



12.70 
0.500 



11.43 
0.450 



10.06 
0,396 



Results 

While the as-quenched specimens had the same random 
texture as the copper powder, distinct evidence of a prefer- 
red orientation or nonuniform texture was found in the 
cold-drawn specimens. As Fig. lb shows, the preferred 
orientation increases from the outside to the center ol a 
drawn bar. and increases with the percent of cold drawing. 

The percentage changes in the lengths and diameters of 
the cylindrical samples for different aging times at 315*C 
(600 Q F) are plotted in Fig. 2. The effects of aging time and 
temperature on the dimensional changes are shown in Figs, 
3 and 4, respectively. 

Discussion 

The decomposition of the supersaturated phase of Cu-Be 
by precipitation has been found by other researchers 45,6 
to be: 

"Atravei&d wire efecincal discharge macti<n& uses a mavmg conductive wire eg an electrode 
Lo erode another conducive part with 3 series- of Tiny eletsneaj sparks 
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6.35 mm 



1 .27 mm 



(a) 



Outside Piece - 
Center Piece 




25-0 mm 




Random Texture of 
Cu Powder { Reference) 



10 20 30 

Diameter Reduction (%) 



<t>) 



Fig. 1. (a) Specimens for the dif- 
fractometry method (b) Nonuni- 
form textures caused by cold 
drawing 



supersaturated a — * GP zone — > y*'-* y r — > 7, 

In a supersaturated phase of this alloy, there is a random 
distribution of Be atoms in a solid solution with Cu atoms . 
The GF (Guinier-Preston) zones are locations where pre- 
cipitates form. 

The equilibrium y phase does not exist in the ranges of 
aging temperature and time used in this experiment. The 
GP zone, 7", and 7' phases consist of multilayered plates 
formed on {100} planes. Shrinkage results from the phase 
transformation because the unit cell dimensions of the GF 
zone, 7", and 7' phases are smaller than those of the a 
phase, as summarized in Table D. 

Table II 
Dimensions of the Unit Cells 



Phase: 


GP zone 7" 


7' 


a 


Lattice: 


tetragonal tetragonal 


cubic 


FGC 


a - h (A) 


2,53 2.53 


2.70 


3.58 


c (A) 


3.22 2.90 


2.7U 


3.58 



where a, b. and c are the unit cell dimensions and FCC 
indicates a face-centered cubic lattice. 

The coherency of the plate-type precipitates allows di- 
mensional change in the direction normal to the plate, but 
prohibits any shrinkage in the habit plane (the flat plane 
in which precipitation plates tend to form]. If this were 
not the case, voids would form at the perimeters of the 
precipitate plates. 

Anisotropic dimensional change on a macroscopic scale 
is the combined effect of: 

■ Microscopic dimensional change caused by each pre- 
cipitate 

■ Formation of the precipitates on habit planes and direc- 
tional shrinkage relative to these planes 

■ Preferred orientation of the habit planes induced by the 
cold drawing process- 
Consider a cylinder of diameter D and length L. Its vol- 
ume V is given by; 



V 



ttD* 



L. 



Upon aging, the vohime change resulling bom small 
changes in both diameter and length is; 



+0.4 -r- 



^+0.2+ y^r^—*---*- 




^ +0.0 -h 



-0.4 -| — \ 



2 4 6 B 10 

Time at 31 5C 600'F (hr) 



0% Cofd 
10% Cold 
20% Cold 
30% Cold 



Drawn 
Drawn 
Drawn 
Drawn 



-0.4 -- ^^ 






*-*- 



2 4 6 8 10 

Time at 315 C SOOT (hrj 



(a) 



(b) 



Fig. 2. Effect of aging time at 

315 Q C on (a) axial and (b) trans- 
verse dimensional changes. 
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dv ~m 

V D 



dL 



(i) 



All of the GP zone, 7", and y* phases are present alter 
aging at 315°C [B0O°F) for a short time/' II is assumed for 
simplicity that only the *y' phase is present after long agiflg 
time (10 hr). The theoretical volume change dVYV after 
complete transformation of the a phase In the 7' phase in 
Cu 1.8 wt% Be was calculated 7 to be: 



dV 
V 



- -0.61%, 



(2) 



This agrees with results from other researchers. 1 *■* By 
combining equations 1 and 2, the plot of dD/D (%] versus 
(1L/L [%) is found to be a straight line: 



D 



■0,5 



dL 



- &3Q5%. 



(3) 



Equal ion 3 is plotted in Figs. 3 and 4 together with the 
experimental data. As shown in Fig. 3, the measured shrink- 
age data of the as-quenched specimens after long aging a I 
315°C (600°F) agrees with the isotropic shrinkage calcu- 
lated from equation 1: 



All 
L 



dD 
D 



1 ^X 
3 V 



« -0.2% 



(41 



Consider a cubic lattice whose [001] direction coincides 
with the bar axis (longitudinal axis ol a cylindrical bar). 
There are only two planes. (001) and (002), perpendicular 
to the bar axis, but there are four planes — (100), (200) P (010), 
and (020) — parallel to 1 his direction. Assume that the prob- 
abilities of forming plate-type precipitates on all {001} 
planes are equal. Since the aging- induced shrinkage is sig- 
nificant in the direction perpendicular to the habit plane 
as pointed out earlier, and since there are more habit planes 
parallel to the bar axis, it can be seen that the transverse 
direction has In shrink more than the axial direction when 
the material lattice structures align themselves after cold 
drawing so that the [001] fiber axis is parallel to the bar axis, 

The experimental data can now be explained, First, since 



the precipitation process happens quickly at 3 1 5 1 G |H(.HJ Q F), 
dimensions of the aged samples change mostly during the 
first hour, then vary slowly as the aging time increases, as 
shown in F'ig, 2. 

Second, the data points start slightly off the anisotropic 
shrinkage line in Fig. 3 at the early stage of precipitation, 
but approach this line as the aging time increases as Indi- 
cated by the direction of the arrows* (Recall that the theoret- 
ical line represents the near-equilibrium condition after 
very long aging time.) Experimental data also suggests that 
the axial dimensions of the textured samples expand to 
conserve their volumes at equilibrium as modeled by equa- 
tions 2 and 3. 

Third, for aging below 260 n C [5Q0°F) T the dimensional 
change of Co -Be is more complicated. As seen in Fig. 4 + 
the as-quenched samples always shrink isotropically be- 
cause of their random oriental ion. The textured samples 
change their dimensions anisotropically but the experi- 
mental data converges to the theoretical line represented 
by equation 3. 

Conclusions and Recommendations 

The anisotropic dimensional change of cold-drawn* then 
aged Cu-Be rods was investigated. This paper shows that: 

■ Gold drawing of Cu-Be forms a distinct [001] fiber tex- 
ture. 

■ The anisotropic dimensional change during an aging pro- 
cess is significantly influenced by the texture. 

■ The as-quenched samples shrink isotropically in the 
temperature range 200 G C to 4B0°C [390°F to 90G*F] be- 
cause of their near-random texture. The textured speci- 
mens change their dimensions anisotropically. The 
transverse dimension of cylindrical samples shrinks but 
the axial dimension expands to conserve their volume 
after long aging at temperatures greater than 315 q C 
(fi00°F). 

■ A more precise shrinkage model should consider the 
different phases in the aged samples, grain boundaries, 
and other volume defects that affect the sample dimen- 
sions. 

■ Dimensional changes are dominated by col d- work-in- 
do ced texture. Therefore, if the amount of cold work is 
controlled, then a fixed set of shrinkage factors for a 
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Fig, 3, Effect of aging time on the 
dimensional change of Cu T 8wt% 
Be. Aging temperature 315 a C 
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Fig. 4. Effect of aging tempera- 
ture on the dimensional change of 

Cu J 8 wt% Be. Aging time 2 hours . 



particular aging process can be used in practice to prcd 1 1 1 
dimensional changes of machined parts. 
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